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 rstruik@gmail.com 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] 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; tls@ietf.org Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 6:42 PM, Dan Brown dbr...@certicom.commailto: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] 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] 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 CA'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
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
[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] sect571r1
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 secp256r1secp384r1secp521r1 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] 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 ynir.i...@gmail.com 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 secp256r1secp384r1secp521r1 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 Wed, Jul 15, 2015 at 1:58 PM, Deirdre Connolly durumcrustu...@gmail.com 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
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
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: tls@ietf.org Subject: Re: [TLS] sect571r1 Tony Arcieri basc...@gmail.com wrote: On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett davemgarr...@gmail.com 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 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: tls@ietf.org Subject: Re: [TLS] sect571r1 On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett davemgarr...@gmail.com 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 Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote: On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett davemgarr...@gmail.com 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
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
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=OpenSSLversion=1.0.1l [2] https://www.ssllabs.com/ssltest/viewClient.html?name=OpenSSLversion=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
[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 version. Note:
