<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks.<br>
<br>
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.<br>
<br>
On 5/25/2023 7:01 PM, Viktor Dukhovni wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ZHAS67PcWuf1_yHH@straasha.imrryr.org">There are good
reasons why that would work poorly. The choice to not mix oil and
water is well motivated.</blockquote>
<br>
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.<br>
<br>
(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.)<br>
<br>
<blockquote type="cite"
cite="mid:ZHAS67PcWuf1_yHH@straasha.imrryr.org">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<pre class="moz-signature" cols="72">--
Jordan Brown, Oracle</pre>
</body>
</html>