https://bugs.exim.org/show_bug.cgi?id=2872
--- Comment #8 from help@??? ---
(In reply to Jeremy Harris from comment #7)
> (In reply to help from comment #6)
> > There can't be any version downgrade-ability
>
> I disagree. If you configure the sever for no-1.3 and hit it with an
> OpenSSL-default 1.3 + 1.2, you get a 1.2 connection. I call that a
> working downgrade, from the point-of-view of the client.
I'd call that a selection rather than a downgrade. A downgrade would constitute
the start of a TLS session in a certain version and the ending of that session
with a different, lower version.
But actually it does not matter how we call it. For the sake of the argument,
it doesn't change anything.
> This is less than useful, it means a server cannot restrict the 1.3 ciphers
> it offers yet still offer both 1.3 and 1.2 service with a single
> configuration.
With a single configuration? Yes. Within a single connection/session? No. And
that's a good thing.
> I'd expect it to, if a (set of) 1.3 ciphers was requested which did
> not match those selected by a peer, to fall back to using a cipher from
> the pre-1.3 set, on a 1.2 connection (assuming there was one). But it does
> not; the server rejects the Client Hello with a "Handshake faiied" alert.
Once a TLS 1.3 session is negotiated, there is no possibility for it to become
a TLS 1.2 session anymore. For good reasons! (Security)
I do not understand where or what the opposition here exactly is. Nobody would
expect a TLS 1.2 session to be downgraded to TLS 1.1 on a cipher-mismatch, so
why the different standard for TLS 1.3 here?
--
You are receiving this mail because:
You are on the CC list for the bug.
