Relationship between TLS 1.3 ciphers and earlier ciphers

[Jordan Brown]

Thanks.

TL;DR:  it sounds like we should just separate the two, one way or
another - fighting against the design isn't worth it.  But I don't
understand the rationale for the design.

On 5/25/2023 7:01 PM, Viktor Dukhovni wrote:
> There are good reasons why that would work poorly. The choice to not
> mix oil and water is well motivated.

Could you elaborate?  My expectation would be that TLS 1.2 connections
would use ciphers that are allowed for 1.2, and TLS 1.3 connections
would use ciphers that are allowed for 1.3, but that we'd only need to
manage one list of ciphers, and a range of acceptable TLS versions.

(We could of course have separate 1.2 and 1.3 lists in the UI, but that
seems like excessive complexity both in the implementation and in the UI.)

> This is an unintentional artefact of the implementation.  The intent is
> to only match TLS 1.3 ciphersuites.  Note that adding a TLS 1.2 cipher
> to the TLS 1.3 ciphersuite list does not make it usable.  Connections
> that negotiate TLS 1.3 fail when this is done.  But TLS 1.2 connections
> succeed with that cipher even when all ciphers are removed from the
> TLS 1.2 and prior cipher list.  Compare:
>
>     $ openssl s_client -tls1_3 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'
>     $ openssl s_client -tls1_2 -connect '...' -ciphersuites TLS_RSA_WITH_AES_256_CBC_SHA -cipher '!ALL'
>
> You could open an issue.  This is more of a nit than a bug, but perhaps
> worth "fixing" nevertheless.

If I'm understanding you correctly, that's exactly the behavior that I
would expect - given a mixed list of 1.2 and 1.3 ciphers, a 1.2
connection would be able to use only the 1.2 ciphers and a 1.3
connection would be able to use only the 1.3 ciphers.  If there are no
ciphers of the appropriate type allowed, the connection would fail.

Side note:  we gave up on using the pre-1.3 pattern matching several
years ago.  It was just too hard to construct the patterns so that they
would match exactly the ciphers that (a) we supported and (b) were
allowed or recommended by our corporate standards.  We had to evaluate a
proposed pattern and then check each resulting cipher; it was easier to
just start with the list of ciphers that we wanted the result to be.

-- 
Jordan Brown, Oracle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230526/362b4dcb/attachment.htm>