I agree with David's analysis. I think, when reasoning about this, we should separate the "how to profile TLS 1.2 down" parts from the "extend TLS 1.2 with more protocol fixes" parts. That's not a knock against those fixes... it's a good thing! Profiling things down is often a configuration-only change to existing TLS 1.2 software, is broadly compatible with existing TLS 1.2 peers, and is covered by existing IETF documents, like RFC 9325.
In contrast, extending TLS 1.2 requires deploying new code and reasoning about transitions. Regarding the DHE extensions, I agree that TLS-LTS shares the same flaws as RFC 7919. https://mailarchive.ietf.org/arch/msg/tls/mWWEJdw_SxAIlvZQnsr1_GiAhQY/ discusses this a bit---the one sentence version is that both RFC 7919 and TLS-LTS would need to have introduced new DHE cipher suite codepoints for it to work. But given the various other flaws in TLS 1.2 DHE (not currently addressed by TLS-LTS), I think it's better to do as draft-ietf-tls-deprecate-obsolete-kex suggests and put our collective deploy-new-software energies into ECDHE. That has the advantage of being compatible with existing TLS 1.2, so it isn't even a deploy-new-software requirement for most folks. Looking through the rest of draft-gutmann-tls-lts, I see the following other changes that aren't covered by simply profiling TLS 1.2: 1. Using both x and y coordinates of ECDH as the secret, instead of just x. 2. Increasing the length of the Finished hash 3. Changing the ServerKeyExchange signature payload to hash the whole transcript thus far (Anything I've missed?) The first of these goes against the standard definition of ECDH (e.g. in SP 800-56A), so it seems implementers would need to break their ECDH abstractions. That, in turn, might have some fun implications w.r.t. various compliance schemes. Of course, security is more important, but the security benefit seems unclear to me... y is computable from x up to one bit. Adding one bit to the output does not seem worth breaking the ECDH abstraction. Unless there's something I've missed (apologies if I've missed some text somewhere!), I think we should drop that one. That leaves 2 and 3. For (2), this WG seems to have largely abandoned tls-unique as a channel binding in favor of exporters. For (3), the specific implementation isn't quite right (see my previous email), but fixable if we change TLS-LTS. Honestly if we had a time machine, I'd use it to incorporate those (but (3) done right) into the EMS extension[*]. I think both issues were already known at the time? But it's not 2015 anymore and it doesn't seem worth the transition costs now. It's true that smaller code changes are less risky than larger code changes, but as Watson notes, TLS 1.3 has now a 6 year headstart to offset that. These issues also don't seem like "urgent security fixes" per draft-ietf-tls-tls12-frozen. If we wanted to take just the "profile TLS 1.2 down" bits and just give it a convenient name, without any wire protocol changes, that might be worthwhile! "Do you implement Better-TLS-1.2?" is much more understandable than "Do you implement EMS, RI, AEAD, ECDHE, etc.?" But that doesn't seem to be what we're discussing here. Also David [*] It would have been *extra* nice if the TLS 1.3 anti-downgrade signal was keyed on better-EMS than TLS 1.3. That would have avoided this mess: https://mailarchive.ietf.org/arch/msg/tls/pixg5cBXHuwd3MtMIn_xIhWmGGQ/ But we don't have a time machine, so this is moot. On Wed, Nov 27, 2024 at 10:00 AM David A. Cooper <david.cooper= 40nist....@dmarc.ietf.org> wrote: > Hello Peter, > > This doesn't really answer my question. I don't have time to read > through the 18 analysis papers. but [TLS-Analysis-14] describes the > Triple Handshake attack. Isn't that fixed by the extended_master_secret > extension (RFC 7627)? If so, then this could be addressed by a guidance > document that mandated support for extended_master_secret (as RFC 9325 > does), and it wouldn't be an example of a bug that could only be fixed > by defining a new (tls_lts) extension. > > TLS-LTS addresses an issue with DHE cipher suites by sending the full > set of DH parameters. Why couldn't the issue be addressed by mandating > that clients offer the supported groups extension with RFC 7919 groups > and mandating that servers only use those groups? (Another option would > be to disallow DHE cipher suites as > https://datatracker.ietf.org/doc/draft-ietf-tls-deprecate-obsolete-kex/ > does.) I understand that draft-gutmann-tls-lts suggests a problem with > RFC 7919 in cases in which it is not supported by both the client and > the server, but I don't see how TLS-LTS solves that. What happens if the > client offers the TLS-TLS extension along with DHE cipher suites, the > server doesn't support TLS-LTS and selects a DHE cipher suite along with > the DH group that the client cannot verify? This isn't an issue if the > client knows the server supports TLS-LTS, but what's the problem with > using RFC 7919 groups if the client knows the server supports them? > > A lot of what is in draft-gutmann-tls-lts is specifying a profile of TLS > 1.2 (e.g., only use this limited set of cipher suites, only use this one > elliptic curve, etc.), or is specifying implementation requirements > (e.g., verify RSA signatures as encode-then-compare). So, most of what > is in the document is profiling existing capabilities, not describing > bugs that can only be addressed by defining a new extension. > > On 11/26/24 6:20 PM, Peter Gutmann wrote: > > David A. Cooper <david.cooper=40nist....@dmarc.ietf.org> writes: > > > >> what bugs would still remain that TLS-LTS fixes? > > This is another thing that's already answered in the draft, for example: > > > > In particular, this document takes inspiration from numerous > > published analyses of TLS [TLS-Analysis-1] [TLS-Analysis-2] > > [TLS-Analysis-3] [TLS-Analysis-4] [TLS-Analysis-5] [TLS-Analysis-6] > > [TLS-Analysis-7] [TLS-Analysis-8] [TLS-Analysis-9] > [TLS-Analysis-10] > > [TLS-Analysis-11] [TLS-Analysis-12] [TLS-Analysis-13] > > [TLS-Analysis-14] [TLS-Analysis-15] [TLS-Analysis-16] > > [TLS-Analysis-17] [TLS-Analysis-18] along with two decades of > > implementation and deployment experience to select a standard > > interoperable feature set that provides the best chance of > long-term > > stability and resistance to attack, as well as guidance on > > implementing this feature set in a sound manner. > > > > Actually I'd end up quoting most of the doc which answers the above > question, > > but for one example: > > > > TLS-LTS sends the full set of DH parameters, X9.42/FIPS 186 style, > > not p and g only, PKCS #3 style. This allows verification of the DH > > parameters, which the current format doesn't allow: > > > > [...] > > * The domain parameters MUST either be compared for equivalence to a > > set of known-good parameters provided by an appropriate standards > > body or they MUST be verified as specified in FIPS 186 [FIPS-186]. > > Examples of the former may be found in RFC 3526 [RFC3526]. > > > > Peter. > > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
