Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 8:52 PM, Jeffrey Walton wrote:
> My bad... I meant over the binary curves.
Per my comments on the other thread ("selection criteria for crypto
primitives"), I think binary curves don't instill confidence and should
probably be removed
--
Tony Arcieri
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Thu, Jul 16, 2015 at 12:17:28AM -0400, Dave Garrett wrote:
> Side question: what is the meaning of the "r" in the naming convention we
> use? (e.g. secp521r1, & sect571r1 vs. sect571k1)
The "r" means that a mysterious seed can be used to "verify" that
the curve paramets are ("nothing up my sleeve") *r*andom.
--
Viktor.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)
Ilari, Thanks for your detailed comments. > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. This was updated in a recent PR by Dave Garrett. > > 1. (Introduction) > > DSA should be replaced by ECDSA (DSA is pretty much obsolete)? Yes, I can do that. I'm happy to remove DSA entirely if the chairs declare consensus on this. > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It's just a changelog. I'll eventually make it a real list in the final version. > > 4.9.1. (Digital Signing) > > I think someone wanted randoms back here in order to support privilege > separation (which I think is important to support, I consider it much > more important than being "HSM friendly")? I think it was Nikos. Nikos, if you'd like to submit a PR that we can discuss, that would be great. > Reading what current draft of 4492-bis says, the hash function used is > determined by signature_algorithms (or presumably the corresponding > mechanism in CertificateRequest for client certs). Well, it's negotiated by that, but indicated in the message. > Also, to my knowledge, there is no mechanism to indicate in ECDSA > certificate what hash algorithms are allowed. I am also unaware of one. > > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) > > The example looks like it belongs to section 4.9.1, as it is about > signatures, not AEAD construct. > Oops. Yeah, I'll fix that. > > 5. (The TLS Record Protocol) > > Documenting the security properties of TLS would be useful... Agreed. I intend to rewrite the entire security analysis soon. > The lack of record length hiding may be problematic in protocols that > have no place for cover traffic (e.g. can DNS requests contain padding, > DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > > > 5.2.1. (Fragmentation) > > Zero-length fragments of application data are very much visible in > ciphertext (unless record padding is added), so those are not currently > useful as traffic analysis countermeasure. Agreed. We have PRs for adding padding, but they haven't been merged yet because I wanted to get key management squared away. See: https://github.com/tlswg/tls13-spec/pull/147 > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). Yes. As you can see there is an open issue marker here. If you wanted to submit a PR, that would be great. > > 6. (The TLS Handshaking Protocols) > > Are encryption keys, finished value (tls-unique) and exporter secret > part of session or not? I'm planning to remove/rewrite this entire section, as I don't think it's useful. > > 6.1.1. (Closure Alerts) > > The semantics of closure alerts seem incompatible with half-closes, > which some protocols actually use. True, but this has been in TLS since the beginning, so there presumably should not be any TLS-using apps which depend on it. Do you think this is a feature which we should add. > > 6.1.2. (Error Alerts) > > Could use another example of warning alert, now that no_renegotiation > is not a warning anymore? Will see what I can find. > > 6.2.1. (Incorrect DHE Share) > > EncryptedExtensions is marked optional in Figure 2, but not Figure 1? It's not optional. I just got confused. Thanks. > The relationship between session hash and handshake restarts seems > like a hairy problem. > > Also, I figured out a downgrade attack that works against careless > _server_ (not requiring client to do anything else than have weak > crypto enabled). Continuing hashes looks to block that attack. > > It involves attacker sending ClientHello with arbitrary parameters > that triggers a retry (very easy to trigger a retry), eating the > reply, followed by sending client's original ClientHello. That > could trigger crypto downgrade in some badly made servers. Do you think you could walk through this in more detail? I'm having trouble understanding the issue. > > 6.2.2. (Cached Server Configuration) > > Issue #184 manifests here too. I think both accepting and provoding > configuration in the same handshake is sensible (key rollover), and > later the draft talks about exactly that case. I agree. > Also, maybe note that provoding the message does not alter the > configuration hash (even if there is no existing one) could be useful. Agreed. Will see what I can do. > > 6.2.3. (Zero-RTT Exchange) > > No EncryptedExtensions? Pilot error. > How would the server know when 0-R
Re: [TLS] sect571r1
> Same kind of auditor who tells you that you can’t replace the library with the > next version that fixes the buffer overflow because it was the previous > version that was certified. In their defense, you do have to prove that this fix was the ONLY change. :) ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Jul 16, 2015, at 6:50 AM, Viktor Dukhovni wrote: > An auditor who believes that we can rigourously quantify the security > of these curves precisely enough to say which is stronger or more > closely "matches" AES-256, should be laughed out of the room and fired. Same kind of auditor who tells you that you can’t replace the library with the next version that fixes the buffer overflow because it was the previous version that was certified. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Wednesday, July 15, 2015 10:31:12 pm Tony Arcieri wrote: > Binary curves in particular are showing warning signs of potential future > security issues: > > https://eprint.iacr.org/2015/310.pdf > > I think even if we don't completely pare down the TLS curve portfolio to > the list I suggested, if nothing else I would like to see binary curves > removed. As of today's draft version on GitHub [0], the only curves permitted in TLS 1.3+ are: secp256r1, secp384r1, secp521r1, & sect571r1 NIST naming [1] of these: P-256, P-384, P-521, & B-571 The other 571-bit is sect571k1 / K-571 (already cut). NIST notation [2] for these names: "P" denotes prime, "B" denotes binary, and "K" denotes Koblitz If there's sufficient evidence that binary curves are likely to be unsafe in the future, then I would certainly consider that to be an additional argument to cut sect571r1. Thus far, I haven't seen much of an argument to keep it. [0] https://tlswg.github.io/tls13-spec/#negotiated-groups [1] https://tools.ietf.org/html/rfc4492#appendix-A [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf Side question: what is the meaning of the "r" in the naming convention we use? (e.g. secp521r1, & sect571r1 vs. sect571k1) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 11:52:13PM -0400, Jeffrey Walton wrote: > > An auditor who believes that we can rigourously quantify the security > > of these curves precisely enough to say which is stronger or more > > closely "matches" AES-256, should be laughed out of the room and fired. > > Maybe so, but it is what it is. The IETF is probably not going to be > able to change it. Well, the auditor can't ask for curves with TLS that the specification deprecates. So removing oddball choices will help users fend off clueless checklist-wielding auditors. A modest amount of diversity is fine, but I would posit that anything beyond a (conservative, performant, backup) triple is counterproductive. Between the anticipated CFRG curves and the NIST prime curves, I think we already have a couple too many. The way I see it: conservative = Goldilocks performant = 25519 backup = P-256, P-384, P-521 (legacy triple) All the above should ultimately be MTI, with each peer prioritizing either "conservantive" or "performant", and legacy peers do the same with "P-256" or "P-384" (with P-521 as backup for both camps). If there are signs that all these are about to fail, and we still somehow are left with some curves we're willing to trust, we can change the mix then. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
>> (I've been through C&A's where matching security levels were examined). > > An auditor who believes that we can rigourously quantify the security > of these curves precisely enough to say which is stronger or more > closely "matches" AES-256, should be laughed out of the room and fired. > Maybe so, but it is what it is. The IETF is probably not going to be able to change it. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 11:48 PM, Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote: >> >> It provides 256-bits of security. Its the only curve I am aware that >> can transport a AES-256 key while maintaining security levels. > > Why do you think P-521 doesn't provide this? My bad... I meant over the binary curves. Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 11:41:03PM -0400, Jeffrey Walton wrote: > > Same here, I think in this case "less is more". There is no > > compelling reason for this curve, and needless diversity here is > > counter-productive. > > It provides 256-bits of security. Its the only curve I am aware that > can transport a AES-256 key while maintaining security levels. It provides a conjectured security level around 256-bits, as does secp521r1. > (I've been through C&A's where matching security levels were examined). An auditor who believes that we can rigourously quantify the security of these curves precisely enough to say which is stronger or more closely "matches" AES-256, should be laughed out of the room and fired. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 8:41 PM, Jeffrey Walton wrote: > It provides 256-bits of security. Its the only curve I am aware that > can transport a AES-256 key while maintaining security levels. Why do you think P-521 doesn't provide this? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
>> >> So, should it stay or should it go now? Opinions? >> > >> > +1 that sect571r1 be removed. >> >> I also believe that it should be removed. > > Same here, I think in this case "less is more". There is no > compelling reason for this curve, and needless diversity here is > counter-productive. > It provides 256-bits of security. Its the only curve I am aware that can transport a AES-256 key while maintaining security levels. (I've been through C&A's where matching security levels were examined). ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 10:42:54 pm Dave Garrett wrote: > The stats also show 1575 "support" it, so I'm not sure what's going on there > specifically. (if someone can explain this bit of those stats, please do) Actually, now that I think about it, it could just be that every single implementation out there prioritizes sect571r1 over sect571k1. So, it has low support, but everything that supports it defaults to sect571r1. Note that both are supported by an order of magnitude fewer servers than secp384r1 and secp521r1. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote: > What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it > has no unexplained constants...). Has it been removed already, or does the > question also refer K-571 too? Already dropped. That's obviously not irreversible, but it's unambiguously in the virtually unused camp. The initial goal was to drop all largely unused curves. This question is just about sect571r1, which is far closer to secp384r1 & secp521r1 in terms of usage, though still notably less. If you want to argue for going with sect571k1 and not sect571r1, I don't think the WG is on-board with that. Even if we continued to allow it, I doubt much would add support for it to be worthwhile. The scan I linked to found one; literally a single server on the entire Internet, that actually supports sect571k1 for ECDHE. The stats also show 1575 "support" it, so I'm not sure what's going on there specifically. (if someone can explain this bit of those stats, please do) https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
To respond more specifically to your concerns: On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik wrote: > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. > Binary curves in particular are showing warning signs of potential future security issues: https://eprint.iacr.org/2015/310.pdf I think even if we don't completely pare down the TLS curve portfolio to the list I suggested, if nothing else I would like to see binary curves removed. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
> It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. > > On a general note, I do not understand what is wrong with having a > dictionary of curves that is well-specified, but whose members are not all > widely used. To my knowledge, having a dictionary does not force everyone to > use every term in this (mandatory vs. optional to implement vs. mandatory to > use, etc.). Related, see Dan Geer's "Heartbleed as Metaphor", http://www.lawfareblog.com/heartbleed-metaphor. Geer says, "Nature teaches that monocultures are so unnatural as to require constant intervention to maintain." Jeff ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
FFDHE with prime field is one big step away from FFDHE with binary field, which has quasipoly time DLP, so that's quite a large risk. ECDHE with binary field is also one big step away from binary FFDHE, but it's a different type of step: hence diversity. I agree that diversity risks weakest link. Ideally, the rainy day backups should be disabled by default, but possible to quickly enable, by administrator configuration or patch. From: Tony Arcieri Sent: Wednesday, July 15, 2015 9:47 PM To: Dan Brown Cc: Martin Rex; Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown mailto:dbr...@certicom.com>> wrote: Even so, there's an argument from Koblitz and Menezes that special curves (e.g. binary curves) may survive some wider collapse. I think it's a weak argument, but for those for whom supporting more curves is easy, it could justify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] (selection criteria for crypto primitives) Re: sect571r1
On Wed, Jul 15, 2015 at 6:42 PM, Rene Struik wrote: > Dear colleagues: > > It seems prudent to keep some diversity of the gene pool and not only have > curves defined over prime curves. Similarly, one should perhaps have some > diversity of gene pool criteria within the set of recommend curves and not > only include special primes. Should some problem with a particular subclass > show up over time, one then at least has other classes available. I just responded to Dan Brown with this, but it applies here as well: -- Forwarded message -- From: Tony Arcieri Date: Wed, Jul 15, 2015 at 6:46 PM Subject: Re: [TLS] sect571r1 To: Dan Brown Cc: Martin Rex , "" On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown wrote: > Even so, there's an argument from Koblitz and Menezes that special curves > (e.g. binary curves) may survive some wider collapse. I think it's a weak > argument, but for those for whom supporting more curves is easy, it could > justify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown wrote: > Even so, there's an argument from Koblitz and Menezes that special curves > (e.g. binary curves) may survive some wider collapse. I think it's a weak > argument, but for those for whom supporting more curves is easy, it could > justify supporting a diversity of curves. Others are pushing FFDHE in the event of some ECC disaster. I'm not really a fan of that either (all these things add attack surface in addition to being "backups"), but if we're going to keep a little used thing around in our pocket just in case of an ECC disaster, why do we need backup curves in addition to FFDHE? -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
Binary curves have some risks, due to recent work of Semaev on subexponential ECDLP, building on much past work. Even so, there's an argument from Koblitz and Menezes that special curves (e.g. binary curves) may survive some wider collapse. I think it's a weak argument, but for those for whom supporting more curves is easy, it could justify supporting a diversity of curves. What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it has no unexplained constants...). Has it been removed already, or does the question also refer K-571 too? The issue of malicious curves seems off-topic to this thread about max curve size, so briefly, to respond to the issue of unexplained constants it is a difficult issue, which CFRG is working on, and NIST too. My thought here is Brainpool deals best with this issue, so far, but it is a far-fetched issue, and other security issues are at least as important. Original Message From: Martin Rex Sent: Wednesday, July 15, 2015 8:21 PM To: Tony Arcieri Reply To: m...@sap.com Cc: Subject: Re: [TLS] sect571r1 Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > Dave Garrett wrote: >> >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 P-256 and P-384 seem to be pretty important to some folks (those with a NIST/NSA Suite B checklist). I'm OK with P-521, but I would prefer to get rid of pretty much all _other_ NIST curves with unexplained parameters, including 571 Either the NIST curves with unexplained constants _are_ backdoored, then you get screwed no matter which one of them you use. Or the NIST curves are OK, then P-521 will be good enough. IMO. -Martin Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521), and MSIE 10 exhibits a curious behaviour on my Win7 machine: when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello with P-521 as the first curve in the named_curve extension. when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello with P-256 as the first curve in the named_curve extension. ___ 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] (selection criteria for crypto primitives) Re: sect571r1
Dear colleagues: It seems prudent to keep some diversity of the gene pool and not only have curves defined over prime curves. Similarly, one should perhaps have some diversity of gene pool criteria within the set of recommend curves and not only include special primes. Should some problem with a particular subclass show up over time, one then at least has other classes available. On a general note, I do not understand what is wrong with having a dictionary of curves that is well-specified, but whose members are not all widely used. To my knowledge, having a dictionary does not force everyone to use every term in this (mandatory vs. optional to implement vs. mandatory to use, etc.). If one follows the line of reasoning of some people on the mailing list earlier today, doesn't this also call into question Brainpool curves, or, e.g., the Misty cipher, etc.? Moreover, this certainly calls into question why one would have a whole set of new DLP groups (which certainly cannot be widely used yet, since the ink to write the parameters down is still wet). What about RSA-1024, etc.? I would suggest one to have a clear criteria by which to judge inclusion/exclusion of cryptographic algorithms. As a final note: if one can define curves explicitly, then removing these from a list does not really remove them, except "pestering" people who would like to use them by forcing sending big chunks of descriptive text instead of short-hand references. Best regards, Rene On 7/15/2015 8:20 PM, Martin Rex wrote: Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] Dave Garrett wrote: It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 P-256 and P-384 seem to be pretty important to some folks (those with a NIST/NSA Suite B checklist). I'm OK with P-521, but I would prefer to get rid of pretty much all _other_ NIST curves with unexplained parameters, including 571 Either the NIST curves with unexplained constants _are_ backdoored, then you get screwed no matter which one of them you use. Or the NIST curves are OK, then P-521 will be good enough. IMO. -Martin Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521), and MSIE 10 exhibits a curious behaviour on my Win7 machine: when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello with P-521 as the first curve in the named_curve extension. when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello with P-256 as the first curve in the named_curve extension. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- email: rstruik@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
Tony Arcieri wrote: [ Charset UTF-8 unsupported, converting... ] > Dave Garrett wrote: >> >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 P-256 and P-384 seem to be pretty important to some folks (those with a NIST/NSA Suite B checklist). I'm OK with P-521, but I would prefer to get rid of pretty much all _other_ NIST curves with unexplained parameters, including 571 Either the NIST curves with unexplained constants _are_ backdoored, then you get screwed no matter which one of them you use. Or the NIST curves are OK, then P-521 will be good enough. IMO. -Martin Microsoft SChannel seems to implent the 3 NIST curves (P-256, P-384, P-521), and MSIE 10 exhibits a curious behaviour on my Win7 machine: when only TLSv1.0 is enabled, then MSIE 10 sends a ClientHello with P-521 as the first curve in the named_curve extension. when TLSv1.2 is also enabled, then MSIE 10 sends a ClientHello with P-256 as the first curve in the named_curve extension. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
This I absolutely cannot agree. P521 must stay, as part of the supported NIST standard (which BTW we use). Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Brian Smith Sent: Wednesday, July 15, 2015 19:40 To: Tony Arcieri Cc: Subject: Re: [TLS] sect571r1 Tony Arcieri wrote: On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 I agree, except that I think we should get rid of P-521 too. Cheers, Brian smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
I don't feel really strongly about this, but I'd prefer to keep P-521. I suggest we remove sect571tr1 now and then we can debate P-521 later. -Ekr On Wed, Jul 15, 2015 at 4:46 PM, Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > >> I agree, except that I think we should get rid of P-521 too. >> > > I'd be fine with that > > -- > Tony Arcieri > > ___ > 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] sect571r1
On Wed, Jul 15, 2015 at 4:40 PM, Brian Smith wrote: > I agree, except that I think we should get rid of P-521 too. > I'd be fine with that -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett > wrote: > >> It's the most used of the rarely used curves. > > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 > I agree, except that I think we should get rid of P-521 too. Cheers, Brian ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On 15 July 2015 at 15:18, Blumenthal, Uri - 0553 - MITLL wrote: > I'd rather not lose the 571 curve. I'd like to understand why you think it's worth keeping. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On 15/07/15 23:27, Rob Stradling wrote: AIUI, OpenSSL's default highest preference curve is sect571r1 (aka B-571). See [1] and [2]. The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, 1) function is that "the highest preference curve is automatically used for ECDH temporary keys used during key exchange." [3] And sure enough, when my SSL scanner (an OpenSSL-based client) scans itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that sect571r1 is used. I haven't explicitly configured it to use this curve. In fact, I would reconfigure it to use secp256r1 if I could find a mod_ssl directive that would let me do that. So I'm wondering if most people using sect571r1 are using it simply because it's a default setting that they can't change, not because they have a particularly strong desire to use it. s/that they can't change// In httpd 2.4, the supported curve(s) can be configured using the SSLOpenSSLConfCmd directive. (Thanks to Steve Henson for pointing me in the right direction just now). +1 to dropping sect571r1 and to Tony's suggestion of further trimming the curve list. [1] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.2 [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com On 15/07/15 22:42, Dave Garrett wrote: On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
AIUI, OpenSSL's default highest preference curve is sect571r1 (aka B-571). See [1] and [2]. The result of calling OpenSSL's recommended SSL_CTX_set_ecdh_auto(ctx, 1) function is that "the highest preference curve is automatically used for ECDH temporary keys used during key exchange." [3] And sure enough, when my SSL scanner (an OpenSSL-based client) scans itself (an httpd/mod_ssl/OpenSSL-based server) [4], it reports that sect571r1 is used. I haven't explicitly configured it to use this curve. In fact, I would reconfigure it to use secp256r1 if I could find a mod_ssl directive that would let me do that. So I'm wondering if most people using sect571r1 are using it simply because it's a default setting that they can't change, not because they have a particularly strong desire to use it. +1 to dropping sect571r1 and to Tony's suggestion of further trimming the curve list. [1] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSL&version=1.0.2 [3] http://openssl.org/docs/ssl/SSL_CTX_set_ecdh_auto.html [4] https://sslanalyzer.comodoca.com/?url=sslanalyzer.comodoca.com On 15/07/15 22:42, Dave Garrett wrote: On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote: > On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > > It's the most used of the rarely used curves. > > I think all "rarely used curves" should be removed from TLS. Specifically, > I think it would make sense for TLS to adopt a curve portfolio like this: > > - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks > - NIST curves (SUPPORTED): P-256, P-384, P-521 > > All other curves should be removed, IMO. This does seem to be the growing consensus. I've submitted a PR to drop it: https://github.com/tlswg/tls13-spec/pull/200/files Unless someone can provide more detail as to why it might be needed to keep around, it looks like the WG wants rid of it. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
I like Tony's recommendation - except that I'd rather not lose the 571 curve. But I'm not going to fight the entire WG over this. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. From: Tony Arcieri Sent: Wednesday, July 15, 2015 18:07 To: Dave Garrett Cc: Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 All other curves should be removed, IMO. smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote: > It's the most used of the rarely used curves. I think all "rarely used curves" should be removed from TLS. Specifically, I think it would make sense for TLS to adopt a curve portfolio like this: - CFRG curves (RECOMMENDED): Curve25519, Ed448-Goldilocks - NIST curves (SUPPORTED): P-256, P-384, P-521 All other curves should be removed, IMO. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote: > It's the most used of the rarely used curves. This statement is potentially confusing, actually, because in comparison to P256 _everything_ is rarely used when it comes to ECDHE. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote: > > The main reason I think this warrants discussion is that dropping it would > > drop the maximum bits here, which whilst obviously not the only factor to > > take into account, will possibly not be desired by some. The main arguments > > for ditching is probably that it might not be safely implemented and nobody > > actually needs something this big. > > Removing it would drop the max number of bits but not necessarily the > max security. The exact security of binary curves is currently under > discussion. The new algorithms offer at best an asymptotic speedup -- > but 571 might be big enough to fall under asymptotics. > > I understand that libraries support it, but is it actually being used? > Does anybody have statistics on how many sites use it? It's the most used of the rarely used curves. https://securitypitfalls.wordpress.com/2015/07/14/june-2015-scan-results/ Server-side support is generally low, however a number of servers prefer to use it for ECDHE. (usage is in the same order of magnitude as P-384 & P-521, though notably less) This is down from the previous month's results but up from the month before. Server support is at a similar rate to other rarely used larger curves, but still a fraction of a percent. Nothing requires it, outright. It's important to note that the dropped range(s) of curves are listed as "MUST NOT" offer or negotiate for any TLS 1.3 implementation, though I haven't added any requirement to enforce that. Dropping it really does drop down the max size drastically, but the general CFRG consensus seems to be that nothing above curve448 is even helpful and secp521r1 would still be permitted for those that want bigger numbers. (given the CFRG opinion, even secp521r1 should be on the chopping block, then) Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 01:59:26PM -0700, Adam Langley wrote: > On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly > wrote: > > > >> So, should it stay or should it go now? Opinions? > > > > +1 that sect571r1 be removed. > > I also believe that it should be removed. Same here, I think in this case "less is more". There is no compelling reason for this curve, and needless diversity here is counter-productive. -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
> The main reason I think this warrants discussion is that dropping it would > drop the maximum bits here, which whilst obviously not the only factor to > take into account, will possibly not be desired by some. The main arguments > for ditching is probably that it might not be safely implemented and nobody > actually needs something this big. > Removing it would drop the max number of bits but not necessarily the max security. The exact security of binary curves is currently under discussion. The new algorithms offer at best an asymptotic speedup -- but 571 might be big enough to fall under asymptotics. I understand that libraries support it, but is it actually being used? Does anybody have statistics on how many sites use it? Tanja ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly wrote: > >> So, should it stay or should it go now? Opinions? > > +1 that sect571r1 be removed. I also believe that it should be removed. Cheers AGL -- Adam Langley a...@imperialviolet.org https://www.imperialviolet.org ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
> So, should it stay or should it go now? Opinions? > +1 that sect571r1 be removed. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
We absolutely should have harmony between 1.3 and 4492bis. Since Uri objected, i'll let the chairs decide if/when we have consensus. -Ekr On Wed, Jul 15, 2015 at 12:52 PM, Yoav Nir wrote: > > > On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche < > benjamin.beurdou...@inria.fr> wrote: > > > > Hey, > > > > Except if someone has a real need for it, > > I would favour removing p571 and keep secp521r1 as the maximum … > > +1 > > It should be noted that I have removed it from RFC4492bis. In terms of > real-world use secp256r1>>secp384r1>>secp521r1 and everything else is lost > in the noise. > > At any rate, if the group decides to keep it, I might as well bring it > back to 4492bis as well. > > Yoav > > ___ > 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] sect571r1
> On Jul 15, 2015, at 9:19 PM, Benjamin Beurdouche > wrote: > > Hey, > > Except if someone has a real need for it, > I would favour removing p571 and keep secp521r1 as the maximum … +1 It should be noted that I have removed it from RFC4492bis. In terms of real-world use secp256r1>>secp384r1>>secp521r1 and everything else is lost in the noise. At any rate, if the group decides to keep it, I might as well bring it back to 4492bis as well. Yoav ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] New cipher suites for SRP
On Mon, June 29, 2015 4:31 am, Hubert Kario wrote: > On Friday 26 June 2015 20:39:24 Geoffrey Keating wrote: >> Dave Garrett writes: >> > On Friday, June 26, 2015 07:48:01 pm Attila Molnar wrote: >> > > Currently SRP cannot be used with newer crypto primitives such as >> > > ciphers in AEAD mode or SHA-2 due to the lack of cipher suites >> enabling >> > > these. There's only 3DES and AES-CBC with SHA-1. >> > > >> > > Would there be support for expanding the SRP cipher suites? >> > >> > I don't think it's a good idea to add new SRP cipher suites. >> > >> > Instead, I think redefining SRP as an extension to PSK would make more >> > sense. Use (EC)DHE_PSK cipher suites with an updated SRP extension to >> get >> > similar capabilities. This would make updating SRP to use newer crypto >> > much easier, as modern PSK cipher suites are easier to get >> standardized. >> > The current SRP spec actually already appears to rely on PSK identity >> > alert codes. >> The problem with that is that there are surely many use cases where >> you're willing to do SRP, or if no SRP you can do a regular ECDHE and >> prompt for the username/password, but PSK is too insecure. >> >> I've been thinking an improved SRP would be useful. It should: >> >> - Specify Modern cipher and hash algorithms as mentioned above >> >> - Replace the existing SHA1+seed with a password whitening function >> like PBKDF2, so that in the event of a compromised server cracking >> the password is harder, and also making online password guessing >> attacks (sending lots of username+password pairs to the server) more >> expensive* >> >> - Deprecate the 1024-bit and the 1536-bit group, and the previous SRP >> ciphersuites; and say that these should only be chosen if the server >> has a legacy verifier for a particular username which requires >> them. > > +1, provided we do two more things: > > - Change the negotiation so that user name is not exchanged in the clear > - Change key exchange to do PFS TLS-pwd already supports both of these. It also supports ECC too, which is problematic with the current SRP protocol. regards, Dan. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
On Wed, Jul 15, 2015 at 11:13 AM, Dave Garrett wrote: > So, should it stay or should it go now? Opinions? I'd prefer to see it removed. There's no good reason to keep it, IMO. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
I’m in favor of keeping sect571r1. I realize it doesn’t get a ton of usage. -- Regards, Uri Blumenthal On 7/15/15, 14:13 , "TLS on behalf of Dave Garrett" wrote: >In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just >the ones actually used. (per Sean's recommendation) One point of >discussion between Eric and myself: sect571r1. I'm in favor of keeping >it, but not very strongly. Eric suggested removing it. It does get some >use, though quite a bit less than the others. > >The main reason I think this warrants discussion is that dropping it >would drop the maximum bits here, which whilst obviously not the only >factor to take into account, will possibly not be desired by some. The >main arguments for ditching is probably that it might not be safely >implemented and nobody actually needs something this big. > >So, should it stay or should it go now? Opinions? > > >Dave > >___ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls smime.p7s Description: S/MIME cryptographic signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] sect571r1
Hey, Except if someone has a real need for it, I would favour removing p571 and keep secp521r1 as the maximum … Cheers, B. > On 15 Jul 2015, at 20:13, Dave Garrett wrote: > > In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the > ones actually used. (per Sean's recommendation) One point of discussion > between Eric and myself: sect571r1. I'm in favor of keeping it, but not very > strongly. Eric suggested removing it. It does get some use, though quite a > bit less than the others. > > The main reason I think this warrants discussion is that dropping it would > drop the maximum bits here, which whilst obviously not the only factor to > take into account, will possibly not be desired by some. The main arguments > for ditching is probably that it might not be safely implemented and nobody > actually needs something this big. > > So, should it stay or should it go now? Opinions? > > > Dave > > ___ > 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] sect571r1
In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the ones actually used. (per Sean's recommendation) One point of discussion between Eric and myself: sect571r1. I'm in favor of keeping it, but not very strongly. Eric suggested removing it. It does get some use, though quite a bit less than the others. The main reason I think this warrants discussion is that dropping it would drop the maximum bits here, which whilst obviously not the only factor to take into account, will possibly not be desired by some. The main arguments for ditching is probably that it might not be safely implemented and nobody actually needs something this big. So, should it stay or should it go now? Opinions? Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)
On Wednesday, July 15, 2015 10:15:23 am Ilari Liusvaara wrote: > Let's review: draft-ietf-tls-tls13-07 Eric obviously does all the heavy lifting here, but I can reply to a few bits in the areas I've touched. > (Note: I omitted some stuff I saw recently discussed (e.g. pruning > unused crypto algorithms) or I remember discussed. I didn't explicitly > check issue list when doing this). Some of these already do have issues/PRs so I'll cite them here along with the bits I have fixed in my WIP branch for the discussions we've been having about alerts and certs. I have quite a few PRs pending review by ekr, at the moment. Note that PR 195 is under my name, but is mostly Sean Turner's commits. It's large and was bitrotted severely over time, so ekr and I had to clean it up. (the original is PR 152 with bits from 150) > > Header > > Isn't 4346 already obsoleted by 5246, which this document also obsoletes? > > 4366 seems to be jointly obsoleted by 5246 and 6066. > > 5246 and 5077 are not in numerical order, whereas the rest are. I have a pending PR that fixes this: https://github.com/tlswg/tls13-spec/pull/198/files > > 1.2. (Major Differences from TLS 1.2) > > Is this meant to be changelog or list of changes? It in current form > looks more like a changelog. It is just a changelog for now. Will definitely need to be replaced by a summary for final RFC. > > 5.2.2. (Record Payload Protection) > > There looks to be latter limits that restrict ciphertext size to 2^14 > +1024, which is smaller than 2^14+2048 here (but those limits might be > tightened further). > > As for amount of expansion needed for length-hiding, I think that being > able to represent 16384-byte record with no padding would be enough > (since record sizes cap at 16384 bytes anyway). https://github.com/tlswg/tls13-spec/issues/55 > I don't think client extensions are optional anymore in TLS 1.3 (being > required for successful handshake. I'll address this in my WIP branch for changes we've been discussing on-list. > > 6.3.1.2. (Server Hello) > > Well, at least it wouldn't be backward compatiblity hazard to remove > session_id_len, since it comes after server version. There's a comment in there from ekr asking if we should remove. The answer is a clear yes, seeing as backwards compatibility is already gone here. https://tools.ietf.org/html/rfc5246#section-7.4.1.3 The compression field was already dropped, so there's no point in having a placeholder for this unless a new placeholder is added for that too. This message does not need to maintain backwards compatibility, though. It can never be sent to a pre-TLS 1.3 client, as the client has to offer 1.3+ for the server to negotiate it. A note that this structure has changed since 1.2 is probably warranted for servers that want to also know how to send a proper one for backwards compatibility, but modifying it here isn't helpful. > > 6.3.1.4. (Hello Extensions) > Some candidates: > - truncated_hmac: Block modes have been removed. [...] > - renegotiation_info: The renego bug is fixed anyway. I have bits for both of these on my WIP branch. (not in any of my PRs pending ekr's review, yet) > > 6.3.1.5.5. (Early Data Indication) > > s/MUST not/MUST NOT/ in description of early_data with client auth? I fixed that in my WIP for all the alert and certs changes we've been discussing on list. > > A.4. (The Cipher Suite) > > Probably remove note about 001C and 001D, since lots of ciphersuites are > now reserved to avoid collisions with old ones. I have a pending PR that updates the whole section. This bit is already dropped. https://github.com/tlswg/tls13-spec/pull/180/files > > C.1. (Random Number Generation and Seeding) > > Replace SHA-1 with SHA-256? Done in my WIP along with rest of SHA-1 deprecation, as was discussed very recently. Dave ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Let's review: draft-ietf-tls-tls13-07 (abridged)
Let's review: draft-ietf-tls-tls13-07 This is abridged version of mail I sent earlier, but was too large for the list due to its sheer size. (Note: I omitted some stuff I saw recently discussed (e.g. pruning unused crypto algorithms) or I remember discussed. I didn't explicitly check issue list when doing this). Note: The issue list could use some cleanup. It has multiple duplicate issues (especially about fixing THS) and also some issues that no longer look applicable. > Header Isn't 4346 already obsoleted by 5246, which this document also obsoletes? 4366 seems to be jointly obsoleted by 5246 and 6066. 5246 and 5077 are not in numerical order, whereas the rest are. > 1. (Introduction) DSA should be replaced by ECDSA (DSA is pretty much obsolete)? > 1.2. (Major Differences from TLS 1.2) Is this meant to be changelog or list of changes? It in current form looks more like a changelog. > 4.9.1. (Digital Signing) I think someone wanted randoms back here in order to support privilege separation (which I think is important to support, I consider it much more important than being "HSM friendly")? Reading what current draft of 4492-bis says, the hash function used is determined by signature_algorithms (or presumably the corresponding mechanism in CertificateRequest for client certs). Also, to my knowledge, there is no mechanism to indicate in ECDSA certificate what hash algorithms are allowed. > 4.9.2. (Authenticated Encryption with Additional Data (AEAD)) The example looks like it belongs to section 4.9.1, as it is about signatures, not AEAD construct. > 5. (The TLS Record Protocol) Documenting the security properties of TLS would be useful... The lack of record length hiding may be problematic in protocols that have no place for cover traffic (e.g. can DNS requests contain padding, DPRIVE WG is apparently planning on putting DNS into (D)TLS?). > 5.2.1. (Fragmentation) Zero-length fragments of application data are very much visible in ciphertext (unless record padding is added), so those are not currently useful as traffic analysis countermeasure. > 5.2.2. (Record Payload Protection) There looks to be latter limits that restrict ciphertext size to 2^14 +1024, which is smaller than 2^14+2048 here (but those limits might be tightened further). As for amount of expansion needed for length-hiding, I think that being able to represent 16384-byte record with no padding would be enough (since record sizes cap at 16384 bytes anyway). > 6. (The TLS Handshaking Protocols) Are encryption keys, finished value (tls-unique) and exporter secret part of session or not? > 6.1.1. (Closure Alerts) The semantics of closure alerts seem incompatible with half-closes, which some protocols actually use. > 6.1.2. (Error Alerts) Could use another example of warning alert, now that no_renegotiation is not a warning anymore? > 6.2.1. (Incorrect DHE Share) EncryptedExtensions is marked optional in Figure 2, but not Figure 1? The relationship between session hash and handshake restarts seems like a hairy problem. Also, I figured out a downgrade attack that works against careless _server_ (not requiring client to do anything else than have weak crypto enabled). Continuing hashes looks to block that attack. It involves attacker sending ClientHello with arbitrary parameters that triggers a retry (very easy to trigger a retry), eating the reply, followed by sending client's original ClientHello. That could trigger crypto downgrade in some badly made servers. > 6.2.2. (Cached Server Configuration) Issue #184 manifests here too. I think both accepting and provoding configuration in the same handshake is sensible (key rollover), and later the draft talks about exactly that case. Also, maybe note that provoding the message does not alter the configuration hash (even if there is no existing one) could be useful. > 6.2.3. (Zero-RTT Exchange) No EncryptedExtensions? How would the server know when 0-RTT data ended, so it could send its ServerHello? Also, how is the 0-RTT data bound to session if accepted, or is there a security analysis for leaving this binding out? Can anyone expand on the note about impersonation with compromised server key? I can't offhand figure out how attacker can calculate server-side ES (without having also compromised (possibly former) client or (current) server exchange key). > 6.3. (Handshake Protocol) Missing encrypted_extensions (it is a handshake message, right)? > 6.3.1.1. (Client Hello) The non-match case gives HelloRetryRequest, not ServerHello, right? s/should/SHOULD/ in description of session_id? I don't think client extensions are optional anymore in TLS 1.3 (being required for successful handshake. Also, TLS 1.2 servers that care about security (are there actually any?) already require extensions for successful handshake. > 6.3.1.2. (Server Hello) Well, at least it wouldn't be backward compatiblity hazard to remove session_id_len, since it comes after server
