https://bugs.exim.org/show_bug.cgi?id=2872
--- Comment #8 from help@novo.media --- (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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
