I did notice one odd thing about the TLS-LTS protocol change (keep in mind this document is *not* deployment considerations, but a whole new incompatible mode for TLS 1.2), regarding domain separation. Unless TLS LTS can fully enforce that the same key is never used for TLS 1.2 LTS and regular TLS 1.2 (on both the authenticating side and the relying party side), we need to worry about the security of the two protocols deployed together.
TLS-LTS changes the signature payload to include the whole transcript so far: https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.1-11.1.1 It also changes the syntax of the ServerDHParams: https://www.ietf.org/archive/id/draft-gutmann-tls-lts-14.html#section-3.2-2.1.1 Now, signing a transcript is definitely a good move, and TLS's DHE construction was very much broken. This is why TLS 1.3 fixed both of these. But when we change the signing payload, we need to think about domain-separation. It should not be possible to take a signature generated in one context and substitute it in another context. The TLS 1.2 ServerKeyExchange signing payload is already fragile. ECDHE and DHE param formats are different, but the cipher suite is not bound into the signature. I don't have the paper off-hand, but I recall there was a near miss where the ECDHE and DHE payloads already nearly overlapped. Given that the new client_server_hello_hash fully overlaps with the old client_random (totally under the client's control) and then the new params overlap with the old server_random (totally under the server's control), it's... not immediately obvious to me whether this is fine. In comparison, TLS 1.3 prepends a context string and also includes a 64-byte prefix to clear the old client and server randoms. The former allows domain separation with future signing payloads, and the latter works around TLS 1.2's lack of a context string. This avoids needing to reason about overlapping payloads and who controls what, except the minimum needed to convince ourselves the 64-byte prefix separates from TLS 1.2 well enough. (Would be nice to avoid that too, but we can't change TLS 1.2's lack of a context string, only make sure we fix this going forward.) https://www.rfc-editor.org/rfc/rfc8446#section-4.4.3 Additionally, if making an incompatible change to TLS 1.2 anyway, rather than adding dh_q to the parameters, I think we've since learned that negotiating named values is the way to go, hence the addition of FFDH values into the NamedGroup registry. (Though there are some other issues with using the same cipher suite values. RFC 7919 did not actually work to save TLS 1.2 DHE.) Of course, details like this are not adoption concerns. Adoption is just a question of whether the WG wants to take on a document as a starting point. I.e., normally, the question we should answer here is "do we want to extend TLS 1.2 to apply the smaller protocol fixes?". However, there was talk in the thread of not wanting to change the protocol anymore, in which case we would be unable to, say, apply TLS 1.3's fix to this. On Wed, Nov 20, 2024 at 12:58 PM Yaron Sheffer <yaronf.i...@gmail.com> wrote: > -1. The TLS working group, and this document in particular, has > consistently ignored the products of the UTA working group. Specifically, > RFC 9325 [1] published a mere two years ago is not even referenced in the > draft, let alone a comparison made with these deployment recommendations > that were made by the very same IETF. (Yes you can hear my frustration > coming through). > > > > Thanks, > > Yaron > > > > [1] https://datatracker.ietf.org/doc/rfc9325/ > > > > > > On 20/11/2024, 19:27, "Andrew Campling" <andrew.campling@419.consulting> > wrote: > > +1, especially given the previous discussion on this topic on the list > back in 2016. > > > > > > Andrew > > > > -----Original Message----- > > From: Salz, Rich <rs...@akamai.com> > > Sent: 05 November 2024 19:01 > > To: Sean Turner <s...@sn3rd.com>; TLS List <tls@ietf.org> > > Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support > > > > I strongly support adoption. > > > > I do not understand why anyone would be opposed to the IETF making > deployment recommendations. I can understand why someone might be bothered > by the impliciation that *THIS ONE WAY* is the only way to get long-term > support, especially if it's seen to contradict our encouragement of TLS > 1.3. But that is an editorial issue that can be easily fixed. > > > > I would like to see this adopted, a short change cycle, and then advanced > in the same cluster with our TLS 1.2 is frozen document. > > > > > > _______________________________________________ > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
