Ilari Liusvaara wrote:
>
> Peter Gutmann wrote:
>
>> Salz, Rich <[email protected]> writes:
>>
>>>> TLS needs an LTS version that you can just push out and leave to its own
>>>> devices
>>>
>>>So don't you have that with TLS 1.1 and appropriate cipher and option
>>>choices?
>>
>> Based on the feedback I've had, I'm kinda tempted to do a TLS 1.2 LTS draft
>> that specifices just a single boolean flag, "use this known-good
>> configuration and not the 6.023e23 other ones and you should be good
>> for the next decade or so". That can then be baked into long-term
>> systems and devices and left alone while people get on with other things.
>
> To actually fix the known problems with TLS 1.2, you would at minimum
> need a new extension, since there is currently no way to fix the broken
> server authentication.
One Boolean signaling is sufficent to fix all of the problems.
one SCSV in the Client->Server direction and a TLS extension Boolean
response in ServerHello.
>
> Then there are the other security fix extensions (at least three already).
> Those all would need to be impiled.
>
> And then there is the TLS 1.2 Diffie-Hellman issue...
TLS 1.2LTS should fix them all at once, including:
- promise to support minimum DHE key lengths >= 2048 bits
whenever ClientHello includes DHE cipher suites
- promise to support a certain small subset of EC curves
and uncompressed point format whenever ClientHello includes
ECDHE cipher suites (but may omit TLS extensions).
- new/improved ServerKeyExchange handshake message, which
does not only contain the reasonable set of DHE parameters,
but also uses a digititally signed covering all prior
handshake messages, not just the two hello randoms.
- overriding any TLS record layer protocol version and
ClientHello.client_version that is less than TLSv1.2
- promise that digital signatures using SHA-256 are supported
- fix the misunderstood semantics of the signature_algorithm extension
so that it is only used as a hint to certificate selection,
but *NEVER* seen as a hard requirement (or reason for server to
abort the TLS handshake based on the signature of the server cert).
-Martin
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
