Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

Thanks for the quick answers.

Yet more naive quick questions: ‎in the reused DH setting could a counter do 
the job of random nonce?‎ doesn't the record layer have an IV or nonce too? (or 
is that passe?).

If these questions are too naive, or too last minute, let me know and I'll 
withdraw them. I did look over 1.3 once, fwiw, but have since forgot the 
details, sorry.
  Original Message
From: Russ Housley
Sent: Monday, July 24, 2017 12:58 PM
To: Dan Brown
Cc: IETF TLS
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's


there was a discussion of adding a statement that a fresh ephemeral key MUST be 
used for each session.  It was decided not to do that.  Without such a 
requirement, nonces are needed.

Russ


> On Jul 24, 2017, at 12:40 PM, Dan Brown  wrote:
>
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given 
> that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not 
> that I truly ever knew).
>
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, is 
> small enough compared to other side channels to justify their added value.
>
>
>  Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> Hiya,
>
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).
>
> Anyway, in TLS1.3 we've gotten rid of the gmt time option
> in the client and server hello, which is good, (and I do
> recall that discussion) but we've also changed from:
>
>   // RFC5246
>   struct {
>  uint32 gmt_unix_time;
>  opaque random_bytes[28];
>   } Random;
>
> to:
>
>   // tls1.3 -21
>   opaque Random[32];
>
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>
> I tried to see where that 28->32 change came from but
> didn't find it (apologies if I missed that). I guess it
> just ensures that the overall length of the struct is
> the same.
>
> So, a question and a possible suggestion:
>
> Q: Why do we need 32 bytes of Random?
>
> Suggestion: if we don't need that much, maybe we could
> change the length there, (I can see that might trigger
> bugs and middlebox issues) or encourage/require folks
> to mask out some of those bits (e.g. with zeros or some
> catchy hex encoded message about dual-ec:-).
>
> Cheers,
> S.
>
>
> [1]
> https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
> [2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consistency for Signature Algorithms?

[Blumenthal, Uri - 0553 - MITLL]

> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or to
bind RSA key sizes to hashes too

 

 

   I don't think that either of these are good ideas.

 

+1

 

Both of these ideas are pretty bad, especially the first one.

 

Listing P-384 as MTI would be just fine, IMHO.

 



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consistency for Signature Algorithms?

[Eric Rescorla]

On Mon, Jul 24, 2017 at 10:15 AM, Hubert Kario  wrote:

> On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> > On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> > >> I'm afraid I don't understand this remark. There is the caveat to
> which
> > >> Ilari alludes, that the server can send whatever chain it has, if the
> > >> server can't send a chain that complies with the client's
> > >> signature_algorithms.  Since certificate validation is assumed to be
> > >> largely a function of the PKI library and not really in scope for the
> > >> TLS spec itself, this is not particularly problematic.
> > >
> > > true; that disjoint between "stuff that TLS library is supposed to do"
> and
> > > "stuff that PKI library is supposed to do" could be spelled out more
> > > explicitly in the RFC though
> >
> > I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> > don't have high hopes that it won't just get closed with no action.
> >
> > >> The other main
> > >> usage of the signature_algorithms limits what can be used in
> > >> CertificateVerify, which is directly relevant to TLS and depends on
> the
> > >> key attested to in the certificate.  Are you claiming that there are
> > >> servers that only possess certificates with p384 keys (i.e., no RSA or
> > >> p256 or other fallback cert)?
> > >
> > > Yes, there are servers that have P-384 keys. Not sure if they have a
> dual
> > > stack (but that is unlikely as only about 30% of servers with ECDSA
> certs
> > > have also RSA cert).
> >
> > To clarify, you are arguing that P-384 should also be listed as MTI?
>
> no, I'm arguing either for dropping the curve from signature algorithms,
> or to
> bind RSA key sizes to hashes too
>


I don't think that either of these are good ideas. It turns out that curves
and
signature algorithms just aren't orthogonal (and even less orthogonal than
hash algorithms) nbut RSA is qualitatively different.

-Ekr


> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] TLS 1.3 presentation language

[Stephen Checkoway]

For the most part, the presentation language (somewhat informally) described in 
section 3 and its use throughout the document is clear, but the use doesn't 
always match the description and some things are written in different ways. I 
have a few examples below of the issues I've noticed. After the examples, I 
make concrete suggestions. To keep the following text as uncluttered as 
possible but still provide easy reference, I've copied the relevant structures 
definitions from Appendix B at the bottom of this message.

Array lengths have four different formats.

- Literal constants. For example, `opaque Random[32];` or `uint8 
CipherSuite[2];`.
- Named, implied constants. For example `coordinate_length` in 
`UncompressedPointRepresentation` which doesn't appear anywhere else, but is 
informally described in the following paragraphs. A variant of this is 
`Hash.length` in the `Finished` struct.
- Qualified field names. I.e., `struct.field`. For example 
`TLSPlaintext.length` in the `TLSPlaintext` and `TLSInnerPlaintext` structs
- Unqualified field names. I.e., `field` where `field` is in the same structure 
as the array. For example `length` in `TLSCiphertext`.

I think the unqualified field names use should be removed. We should write 
`TLSCiphertext.length` instead. I think this is the only place that the 
unqualified field name appears.

`Hash.length` and `coordinate_length` are both doing the same thing. I think 
they should be written in the same way. `Hash` isn't a defined structure that 
has fields so it makes sense to me to go with `hash_length`. (This would also 
simplify parsing the presentation language.)


Next, most uses of `select` don't match the presentation language's definition. 
Here's the general definition.

  struct {
  T1 f1;
  T2 f2;
  
  Tn fn;
  select (E) {
  case e1: Te1;
  case e2: Te2;
  
  case en: Ten;
  } [[fv]];
  } [[Tv]];

The definition isn't explicit, but it appears that the `Te1`, ..., `Ten` should 
be types but most uses outside of section 3 are _not_ types. The only use of 
`select` that appears to match the example is in the `Handshake` struct. 
`KeyShare` and `PreSharedKeyExtension` have  additional fields in their `case` 
statements and, somewhat confusingly, `EarlyDataIndication`'s `case` statements 
contain both fields and types.

In addition, the only one of those structs to use the optional label on the 
`select` is `Handshake`.

I think we should make the presentation language definition actually conform to 
its use which means we either need to change the definition or change the uses. 
Options include

1. Add anonymous structs around all of the fields in each `case` statement.
2. Add auxiliary structure definitions (like we have for `struct {} Empty;` 
already) and use the type names for each `case` statement.
2. Change the definition of the `case` statements from types to a sequence of 0 
or more fields. Something like
  struct {
  T1 f1;
  T2 f2;
  
  Tn fn;
  select (E) {
  case e1:
  Te1_1 fe1_1;
  Te1_2 fe1_2;
  
  Te1_m fe1_m;
  case e2:
  Te2_1 fe2_1;
  Te2_2 fe2_2;
  
  Te2_m fe2_m;
  
  case en:
  Ten_1 fen_1;
  Ten_2 fen_2;
  
  Ten_m fen_m;
  } [[fv]];
  } [[Tv]];

Option 1 adds a bunch of otherwise-useless `struct`s inline with the case 
statements making them harder to read. Option 2 is going to be slightly easier 
to read but still adds a bunch of structs. Option 3 complicates the definition 
of `select` but better conforms with what we actually do.

Two additional benefits of option 3 are that we could remove the optional 
`select` field label (the `[[fv]]`) and we can get rid of the `Empty` 
structure. The only `select` that actually uses that label is `Handshake` and I 
don't think that label is ever referred to.


Concretely, I think we should make the following changes.
1. Replace `length` with `TLSCiphertext.length` in the definition of 
`TLSCiphertext`.
2. Replace `Hash.length` with `hash_length` throughout (9 instances).
3. Change the definition of `select`'s `case` statements to have 0 or more 
fields (types and names) and remove the optional label.
4. Change the `select` example to match the new definition.
5. Change `Handshake` by adding field names to each `case` statement. (These 
could all be `body` or they could be unique.) Remove the `body` label.
6. Delete the `Empty` structure and replace both current uses with the comment 
`/* Empty */`.

Thoughts?

Copied from Appendix B for reference.

  struct {
  uint8legacy_form = 4;
  opaque   X[coordinate_length];
 

Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario]

On Monday, 24 July 2017 15:09:48 CEST Benjamin Kaduk wrote:
> On 07/24/2017 05:49 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> >> I'm afraid I don't understand this remark. There is the caveat to which
> >> Ilari alludes, that the server can send whatever chain it has, if the
> >> server can't send a chain that complies with the client's
> >> signature_algorithms.  Since certificate validation is assumed to be
> >> largely a function of the PKI library and not really in scope for the
> >> TLS spec itself, this is not particularly problematic.
> > 
> > true; that disjoint between "stuff that TLS library is supposed to do" and
> > "stuff that PKI library is supposed to do" could be spelled out more
> > explicitly in the RFC though
> 
> I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
> don't have high hopes that it won't just get closed with no action.
> 
> >> The other main
> >> usage of the signature_algorithms limits what can be used in
> >> CertificateVerify, which is directly relevant to TLS and depends on the
> >> key attested to in the certificate.  Are you claiming that there are
> >> servers that only possess certificates with p384 keys (i.e., no RSA or
> >> p256 or other fallback cert)?
> > 
> > Yes, there are servers that have P-384 keys. Not sure if they have a dual
> > stack (but that is unlikely as only about 30% of servers with ECDSA certs
> > have also RSA cert).
> 
> To clarify, you are arguing that P-384 should also be listed as MTI?

no, I'm arguing either for dropping the curve from signature algorithms, or to 
bind RSA key sizes to hashes too

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Colm MacCárthaigh]

On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd  wrote:

> Don't use bad prngs. And don't buy products from vendors who ship back
> doors and refuse to come completely clean when confronted.
>

Just yesterday DJB posted a blog post about AES-CTR-DRBG, one of the most
widely-used PRNGs, and he points out a security optimization that can be
applied to it, one that escaped years of review. The optimization only
applies if you're generating large chunks of random data, so doesn't apply
to TLS, where the chunks are small; but it's still interesting that we're
still finding improvements and problems in this area.

The PRNG sits at the very bottom of the security of TLS, and biases there
have the potential to break everything, including back in time; they could
defeat PFS and uncloak years worth of data. We don't always know what's bad
t the time that we are using it; e.g. arc4random was considered fine for
years.

I think it's wise to take some measures to handle the "Well, if it were
broken, how would we add defense in depth ...".

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Colm MacCárthaigh]

On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell 
wrote:

> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
>

I think the fix for this is really at the application level; if you want
defense-in-depth against PRNG problems, it's probably best to use separate
RNG instances for public data (e.g. client_random, server_random,
explicit_IV) and for secret data (keys) so that a leak in the public data
doesn't compromise the private one. We do this in s2n, and I think
BouncyCastle does it too.

A protocol level fix probably isn't as helpful because the attacker can
make more connections and collect more data to derive more and more
information about the RNG state anyway.

-- 
Colm
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Russ Housley]

there was a discussion of adding a statement that a fresh ephemeral key MUST be 
used for each session.  It was decided not to do that.  Without such a 
requirement, nonces are needed.

Russ


> On Jul 24, 2017, at 12:40 PM, Dan Brown  wrote:
> 
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given 
> that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not 
> that I truly ever knew).
> 
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, is 
> small enough compared to other side channels to justify their added value.
> 
> 
>  Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
> 
> 
> Hiya,
> 
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at the slides [1]
> or reading the paper [2] or watching the video wherever
> that may be;-).
> 
> Anyway, in TLS1.3 we've gotten rid of the gmt time option
> in the client and server hello, which is good, (and I do
> recall that discussion) but we've also changed from:
> 
>   // RFC5246
>   struct {
>  uint32 gmt_unix_time;
>  opaque random_bytes[28];
>   } Random;
> 
> to:
> 
>   // tls1.3 -21
>   opaque Random[32];
> 
> Now if some TLS1.3 deployment were affected by a dual-ec
> attack, it'd seem like the -21 version of Random might be
> even better than the TLS1.2 version, for the attacker.
> 
> I tried to see where that 28->32 change came from but
> didn't find it (apologies if I missed that). I guess it
> just ensures that the overall length of the struct is
> the same.
> 
> So, a question and a possible suggestion:
> 
> Q: Why do we need 32 bytes of Random?
> 
> Suggestion: if we don't need that much, maybe we could
> change the length there, (I can see that might trigger
> bugs and middlebox issues) or encourage/require folks
> to mask out some of those bits (e.g. with zeros or some
> catchy hex encoded message about dual-ec:-).
> 
> Cheers,
> S.
> 
> 
> [1]
> https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
> [2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Ilari Liusvaara]

On Mon, Jul 24, 2017 at 04:40:24PM +, Dan Brown wrote:
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all,
> given that ephemeral DH is mandated, if anybody has the time/
> patience. (* ok, not that I truly ever knew).

Two reasons:

- The DH shares can be reused (even if this is bad practice, there is
  no requirement not to).
- There still is pure-PSK mode, which has no entropy injection apart
  from Random values.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Dan Brown]

Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given 
that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not 
that I truly ever knew).

I assume that the risk of misusing the nonces, to exfiltrate keys etc, is small 
enough compared to other side channels to justify their added value.


  Original Message
From: Stephen Farrell
Sent: Monday, July 24, 2017 11:15 AM
To: tls@ietf.org
Subject: [TLS] 32 byte randoms in TLS1.3 hello's


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis

[David Benjamin]

I believe what Raja is pointing out is that a server which accepts an ECDSA
*client* certificate has no way to advertise to the client which curves it
accepts. The signature algorithm list (and before TLS 1.2, the certificate
types) do advertise ECDSA as a whole, but not curves. E.g., a client with
both a P-256 and P-384 certificate may send P-384 when the server only
accepted P-256. This issue existed in RFC 4492 as well.

Though I wouldn't say the implication is all curves must be implemented.
Rather I think you just reject those curves you don't accept and manage
your client certificate deployment so that all servers accept a curve
before starting to use those certificates.

That's not great, so TLS 1.3 fixes this by moving ECDSA curves into
signature algorithms. It's too late to change supported_groups to allow a
TLS 1.2 ServerHello acknowledgement since clients will unexpected server
extensions[*], so I would suggest we just leave this in the awkward state
for TLS 1.2 and say it is fixed in TLS 1.3.

David

[*] Although, glancing through ours, it seems we do accept and ignore a
ServerHello supported_groups in TLS 1.2. We apparently came across a server
implementation which sent it, contrary to the spec.

On Mon, Jul 24, 2017 at 10:58 AM Ilari Liusvaara 
wrote:

> On Mon, Jul 24, 2017 at 01:48:13PM +, Raja ashok wrote:
> > Hi Nir, Josefsson & Pegourie,
> >
> > As per section 5.2 server should send only "Supported Point Format"
> > extensions in server hello message. And it doesn't require to send
> > "Supported Elliptic Curve" extensions. Because of this if server is
> > supporting only few Curves and if it receives unsupported Elliptic
> > curve in client certificate message, then server might not be able
> > to continue the handshake.
>
> In TLS 1.2, the client sends the list of curves (and other groups
> and DHFs) it supports. The server picks one if it can.
>
> Thus if there is at least one common curve that both client and
> server support, then the group selection will succeed (if there
> is none, then no matter what one does things won't work).
>
> The actual curve server selected is transmitted in ServerKeyExchange
> message.
>
>
> In TLS 1.3, things get bit more complicated, since client can
> signal it supports a group without sending a share for it (if
> server selects such group, it needs to tell the client to retry
> using HelloRetryRequest message). The server group selection is
> in KeyShare extension in ServerHello message.
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consistency for Signature Algorithms?

[Viktor Dukhovni]

On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:

> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.

"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain.  I sure
hope that server implementation that abort instead of sending some
chain will be rare.

It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:

1.  Negotiate algorithms suitable for signing TLS handshake
messages.

2.  Signal support for X.509 signature algorithms.

Using the same extension for both was perhaps a mistake.  As pointed
out in this thread,  X.509 admits more combinations for "2" than
TLS 1.3 does for "1".  Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 32 byte randoms in TLS1.3 hello's

[Watson Ladd]

On Jul 24, 2017 8:15 AM, "Stephen Farrell" 
wrote:


Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).


Anti-kleptography is not a matter of avoiding known attacks one at a time.
The fact is that someone could add backdoor login credentials or a buffer
overflow if they can also force dual-
EC to be used.

Don't use bad prngs. And don't buy products from vendors who ship back
doors and refuse to come completely clean when confronted.


Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-
checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ilari Liusvaara]

On Mon, Jul 24, 2017 at 10:03:28AM -0400, Brian Sniffen wrote:
> Ted Lemon  writes:
> 
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL 
> >  wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a 
> >> protocol that’s assumed to be secure.
> >
> > You don't seem to be hearing what I'm trying to say.   What you are
> > proposing is physically impossible.
> 
> Is it?  I could imagine making the server ECDH share dependent on the
> client ECDH share, plus a local random value.  At the end of the
> session, the server discloses that random value, showing that it
> properly constructed a fresh ECDH share.

I do not think this works. As a blatant example, have server generate
the ServerRandom and then the ECDH seed using Dual-EC-DRBG...

The ECDH share will then change every connection and there is a
seed to demonstrate, but the connections can still be decrypted by who
controls the Dua-EC-DRBG backdoor key.

Yes, Dual-EC-DRBG is quite crappy with sizable biases, but discovering
those would take way too many connections. And there are similar
methods that have much much smaller biases.


Basically, if implementation wants to be secretly evil, it can be
secretly evil, and there is nothing you can do to discover it remotely.

Bad implementations are a separate problem. E.g., repeating the same
DH share for a long time because there is no key rotation. That sort
of behavior is pretty blatant if one monitors the DH shares used.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] 32 byte randoms in TLS1.3 hello's

[Stephen Farrell]

Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
  uint32 gmt_unix_time;
  opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Cheers,
S.


[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Sean Turner]

> On Jul 24, 2017, at 16:27, Paul Turner  wrote:
> 
>  
> It's fascinating that people cannot seem to stop picking at the scab 
> remaining after draft-green. I really think we'd be wiser to just let the 
> wound heal. (And get on with the work that this WG has been chartered to do, 
> which does not include
> wiretapping.)
>  
> Sorry to ask for this so late in the conversation but can you point me to the 
> definition of the term “wiretapping” you’re using?

Paul,

Check out https://datatracker.ietf.org/doc/rfc2804/

spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Doubts in draft-ietf-tls-rfc4492bis

[Ilari Liusvaara]

On Mon, Jul 24, 2017 at 01:48:13PM +, Raja ashok wrote:
> Hi Nir, Josefsson & Pegourie,
> 
> As per section 5.2 server should send only "Supported Point Format"
> extensions in server hello message. And it doesn't require to send
> "Supported Elliptic Curve" extensions. Because of this if server is
> supporting only few Curves and if it receives unsupported Elliptic
> curve in client certificate message, then server might not be able
> to continue the handshake.

In TLS 1.2, the client sends the list of curves (and other groups
and DHFs) it supports. The server picks one if it can.

Thus if there is at least one common curve that both client and
server support, then the group selection will succeed (if there
is none, then no matter what one does things won't work).

The actual curve server selected is transmitted in ServerKeyExchange
message.


In TLS 1.3, things get bit more complicated, since client can
signal it supports a group without sending a share for it (if
server selects such group, it needs to tell the client to retry
using HelloRetryRequest message). The server group selection is
in KeyShare extension in ServerHello message.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Kyle Rose]

On Mon, Jul 24, 2017 at 10:33 AM, Paul Turner  wrote:

>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.
>
>
>
> Is the objective to have the protocol prevent an endpoint “surreptitiously
> doing evil”?
>

To the extent it can, it should (within bounds of performance,
deployability, etc.). Many of us have been pointing out that there are
limits to what's possible, and tradeoffs involved in other facets.

Also, can you define what you mean by evil?
>

I am using it as shorthand in this conversation for the general notion of
actively enabling pervasive surveillance, which might be logging keys to a
government server or using a government-generated DH share, among other
possibilities. I am happy to use a different phrasing, but this one is
useful because it's pithy: it invokes intent, which separates it
conceptually from other classes of peer trust violations.

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Paul Turner]

 

Of course, this is precisely the point. All your proposal does is complicate 
the process of sharing sessions with a third-party: it doesn't stop an endpoint 
from surreptitiously doing evil.

 

Is the objective to have the protocol prevent an endpoint “surreptitiously 
doing evil”? Also, can you define what you mean by evil?

 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Brian Sniffen]

Kyle Rose  writes:

> On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen  wrote:
>
>> I could imagine making the server ECDH share dependent on the
>> client ECDH share, plus a local random value.  At the end of the
>> session, the server discloses that random value, showing that it
>> properly constructed a fresh ECDH share.
>>
>> Then the client has an opportunity to notice---this session didn't have
>> a (retrospective) proof of proper generation of the server ECDH share,
>> and so may involve key reuse in a dangerous way.
>>
>> This doesn't stop the server from logging the session key, of course.
>>
>
> Of course, this is precisely the point. All your proposal does is
> complicate the process of sharing sessions with a third-party: it doesn't
> stop an endpoint from surreptitiously doing evil.

Yes, but it adds a storage requirement in proportion to the number of
evil acts taken.  For the same reason we find large-key cryptography
interesting---now the adversary has to smuggle out megabytes---we might
like this.

> (Your proposal is
> interesting, but because it neatly solves the problem of DH share reuse
> without requiring some kind of CT-like infrastructure, not because it
> somehow addresses the evil endpoint problem. On the downside, it also may
> have implications for amplification DoS.)

Yes: I'd expect a large operator to drop support for this extension
under load, exactly when they switch to pre-generated ECDH keys.  When
they must further switch to re-used keys, that will be silent.

Conversation elsewhere raises a practical point: browsers don't want to
alert the user on every aborted connection.  But a bad server can
accept this extension, reuse a ECDH share, and then RST the
connection rather than properly terminate it.  All I can offer there is
the idea that the client *should* alert when *it* closes the connection
and doesn't get back a proof of proper key generation.

-Brian

-- 
Brian Sniffen 
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Paul Turner]

It's fascinating that people cannot seem to stop picking at the scab remaining 
after draft-green. I really think we'd be wiser to just let the wound heal. 
(And get on with the work that this WG has been chartered to do, which does not 
include

wiretapping.)



Sorry to ask for this so late in the conversation but can you point me to the 
definition of the term “wiretapping” you’re using?



Paul
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Kyle Rose]

On Mon, Jul 24, 2017 at 10:03 AM, Brian Sniffen  wrote:

> Ted Lemon  writes:
>
> > On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL <
> u...@ll.mit.edu> wrote:
> >> What I am trying to avoid is the ability to *surreptitiously* subvert a
> protocol that’s assumed to be secure.
> >
> > You don't seem to be hearing what I'm trying to say.   What you are
> > proposing is physically impossible.
>
> Is it?  I could imagine making the server ECDH share dependent on the
> client ECDH share, plus a local random value.  At the end of the
> session, the server discloses that random value, showing that it
> properly constructed a fresh ECDH share.
>
> Then the client has an opportunity to notice---this session didn't have
> a (retrospective) proof of proper generation of the server ECDH share,
> and so may involve key reuse in a dangerous way.
>
> This doesn't stop the server from logging the session key, of course.
>

Of course, this is precisely the point. All your proposal does is
complicate the process of sharing sessions with a third-party: it doesn't
stop an endpoint from surreptitiously doing evil. (Your proposal is
interesting, but because it neatly solves the problem of DH share reuse
without requiring some kind of CT-like infrastructure, not because it
somehow addresses the evil endpoint problem. On the downside, it also may
have implications for amplification DoS.)

Kyle
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Brian Sniffen]

Ted Lemon  writes:

> On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL  
> wrote:
>> What I am trying to avoid is the ability to *surreptitiously* subvert a 
>> protocol that’s assumed to be secure.
>
> You don't seem to be hearing what I'm trying to say.   What you are
> proposing is physically impossible.

Is it?  I could imagine making the server ECDH share dependent on the
client ECDH share, plus a local random value.  At the end of the
session, the server discloses that random value, showing that it
properly constructed a fresh ECDH share.

Then the client has an opportunity to notice---this session didn't have
a (retrospective) proof of proper generation of the server ECDH share,
and so may involve key reuse in a dangerous way.

This doesn't stop the server from logging the session key, of course.

I *think* the shape I describe above fits into an extension, so (a) it
doesn't have to be done to ship TLS 1.3, and (b) it can be available for
use in general purpose browsers, and then disabled for the "enterprise"
case, and (c) I don't have to worry through the performance implications
of not being able to pre-generate a stack of ECDH shares.

-Brian

-- 
Brian Sniffen 
Information Security: Safety, Adversarial Resilience, Tools, Compliance
/(* Akamai - Faster Forward

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Doubts in draft-ietf-tls-rfc4492bis

[Raja ashok]

Hi Nir, Josefsson & Pegourie,

As per section 5.2 server should send only "Supported Point Format" extensions 
in server hello message. And it doesn't require to send "Supported Elliptic 
Curve" extensions. Because of this if server is supporting only few Curves and 
if it receives unsupported Elliptic curve in client certificate message, then 
server might not be able to continue the handshake.
This makes (D)TLS server should mandatory implement all the curves mentioned in 
"NamedCurve". But I feel mandating (D)TLS server to support all NamedCurve is 
not feasible, as in future if new named curves are defined then updating legacy 
server is not easy. And also constraint (D)TLS server generally doesn't support 
all the curves.
Please provide your suggestion on this. If my understanding is wrong, please 
correct me.

Regards,
Ashok


[Company_logo]

Raja Ashok V K
Huawei Technologies
Bangalore, India
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consistency for Signature Algorithms?

[Benjamin Kaduk]

On 07/24/2017 05:49 AM, Hubert Kario wrote:
> On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
>> I'm afraid I don't understand this remark. There is the caveat to which
>> Ilari alludes, that the server can send whatever chain it has, if the
>> server can't send a chain that complies with the client's
>> signature_algorithms.  Since certificate validation is assumed to be
>> largely a function of the PKI library and not really in scope for the
>> TLS spec itself, this is not particularly problematic.  
> true; that disjoint between "stuff that TLS library is supposed to do" and 
> "stuff that PKI library is supposed to do" could be spelled out more 
> explicitly in the RFC though

I pasted that into https://github.com/tlswg/tls13-spec/issues/1062 but I
don't have high hopes that it won't just get closed with no action.

>> The other main
>> usage of the signature_algorithms limits what can be used in
>> CertificateVerify, which is directly relevant to TLS and depends on the
>> key attested to in the certificate.  Are you claiming that there are
>> servers that only possess certificates with p384 keys (i.e., no RSA or
>> p256 or other fallback cert)?
> Yes, there are servers that have P-384 keys. Not sure if they have a dual 
> stack (but that is unlikely as only about 30% of servers with ECDSA certs 
> have 
> also RSA cert).

To clarify, you are arguing that P-384 should also be listed as MTI?

-Ben
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consistency for Signature Algorithms?

[Hubert Kario]

On Friday, 21 July 2017 21:37:42 CEST Benjamin Kaduk wrote:
> On 07/21/2017 09:34 AM, Hubert Kario wrote:
> > On Friday, 21 July 2017 15:38:32 CEST Benjamin Kaduk wrote:
> >> On 07/21/2017 08:23 AM, Hubert Kario wrote:
> >>> Signature Algorithms for ECDSA now define both the curve and the hash
> >>> 
> >>> algorithm:
> >>>   ecdsa_secp256r1_sha256(0x0403),
> >>>   ecdsa_secp384r1_sha384(0x0503),
> >>>   ecdsa_secp521r1_sha512(0x0603),
> >>> 
> >>> This is in contrast to the TLS 1.2 protocol, where any hash can be used
> >>> with any curve.
> >> 
> >> I assume you saw
> >> https://www.ietf.org/mail-archive/web/tls/current/msg23714.html which
> >> raised a different question in this same general area.
> >> 
> >> I do not see how the response here cannot be the same as it was there:
> >> namely, that the current formulation is assumed to have WG consensus,
> >> having been through two WGLCs; there would need to be rather strong
> >> reasons to make changes at this stage.
> > 
> > MTI (section 9.1) says only that ecdsa_secp256r1_sha256 is mandatory
> > (MUST)
> > and no word about any of the other two.
> > 
> > given that we already have CAs that use P-384 for signatures. I'd say this
> > is a big conflict between theory and practice.
> 
> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.  Since certificate validation is assumed to be
> largely a function of the PKI library and not really in scope for the
> TLS spec itself, this is not particularly problematic.  

true; that disjoint between "stuff that TLS library is supposed to do" and 
"stuff that PKI library is supposed to do" could be spelled out more 
explicitly in the RFC though

> The other main
> usage of the signature_algorithms limits what can be used in
> CertificateVerify, which is directly relevant to TLS and depends on the
> key attested to in the certificate.  Are you claiming that there are
> servers that only possess certificates with p384 keys (i.e., no RSA or
> p256 or other fallback cert)?

Yes, there are servers that have P-384 keys. Not sure if they have a dual 
stack (but that is unlikely as only about 30% of servers with ECDSA certs have 
also RSA cert).


On Friday, 21 July 2017 17:00:55 CEST Ilari Liusvaara wrote:
> Actually, P-256+SHA512 is allowed with a caveat, even if the
> certificate is not self-signed. And with the same caveat, server can
> send a certificate signed with P-256+SHA3-512, despite TLS
> codepoint for it having never existed (not many clients can validate it
> through).

the reverse is true too - if your TLS library supports some combinations, the 
PKIX library MUST support them
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Stephen Farrell]

It's fascinating that people cannot seem to stop picking at
the scab remaining after draft-green. I really think we'd be
wiser to just let the wound heal. (And get on with the work
that this WG has been chartered to do, which does not include
wiretapping.)

On 23/07/17 18:17, Felix Wyss wrote:
> How about requiring a record of a fixed size that either contains the
> session key encrypted with a “leaking key” or the output of a stream
> cipher keyed with the session key.  A 3rd party observer would not be
> able to determine whether the session key is being leaked but the
> client can tell and act accordingly.

The relevant signal is that a TLS deployment is able to be
wiretapped. It doesn't matter how that signal is sent, via
rfc1149 or in-band. Adding your putative field (which is
eerily reminiscent of a Clipper LEAF) is such a signal, and
it doesn't matter what content is in the field today, the
"local" authorities will see that and send you the key to
use for them.

See also the many earlier points about consent, naming etc
etc.

S.

> 
> --Felix
> 
> From: TLS  on behalf of Ted Lemon
>  Date: Sunday, July 23, 2017 at 16:34 To:
> "Blumenthal, Uri - 0553 - MITLL"  Cc:
> ""  Subject: Re: [TLS] datacenter TLS
> decryption as a three-party protocol
> 
> I did a little bit of rubber-duck debugging on this proposal with
> Andrea on the way back from Boston this morning.   It's actually
> better for the server to secretly use a static key than to negotiate.
> Stephen has already explained why: if this is a negotiation, then
> it's possible for a third party to simply block any negotiation that
> doesn't allow it.   We have no control over evil endpoints, and it's
> silly to pretend otherwise.   Pretending otherwise makes us less
> secure, not more secure.
> 
> 
> 
> ___ TLS mailing list 
> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ted Lemon]

On Jul 23, 2017, at 9:01 PM, Blumenthal, Uri - 0553 - MITLL  
wrote:
> What I am trying to avoid is the ability to *surreptitiously* subvert a 
> protocol that’s assumed to be secure.

You don't seem to be hearing what I'm trying to say.   What you are proposing 
is physically impossible.   It is always possible to surreptitiously subvert 
the protocol.   This is not an achievable goal.   What you get if you implement 
what you are proposing is a protocol that's easier for an on-path attacker to 
subvert, not a protocol that is harder for an end-point attacker to subvert.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls