[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

[David Benjamin <[e-mail]>]

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 <[e-mail]>
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" <[e-mail]>
> wrote:
>
> +1, especially given the previous discussion on this topic on the list
> back in 2016.
>
>
>
>
>
> Andrew
>
>
>
> -----Original Message-----
>
> From: Salz, Rich <[e-mail]>
>
> Sent: 05 November 2024 19:01
>
> To: Sean Turner <[e-mail]>; TLS List <[e-mail]>
>
> 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 -- [e-mail]
>
> To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> TLS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>