Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 19, 2018, at 4:24 PM, Salz, Rich wrote: > > Viktor found my comment offensive, which was not my intent. I was trying to > be light-hearted in commenting on how Viktor dismissed all the issues David > raised. > > If, in doing so, I went beyond our code of conduct

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote: > > I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or > something like that. You'll need to retract that. -- Viktor. ___ openssl-project

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 19, 2018, at 3:15 PM, Kurt Roeckx wrote: > > I think there might be some disagreement on how to go forward with > having proper TLS in SMTP. I think Google might want to go with > how it works for https, and so have certificates issued by a CA > for hostname you try to

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

On Thu, Apr 19, 2018 at 09:15:19PM +0200, Kurt Roeckx wrote: > > It would also be nice that if the client sends an SNI and you have > a certificate for it that it wouldn't select an anonymous cipher. > But then postfix is probably the only one that does anonymous > ciphers, and if it's not

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote: > > > > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni > > wrote: > > > > There is no "the name that is being verified". The Postfix SMTP client > > accepts multiple (configurable as a set) names for

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or something like that. David has pointed out valid use-cases. I think most use-cases will "just work." We should document the known sharp edges. ___ openssl-project

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote: > > Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1 does > not work in TLS 1.3, only PSS. That's a local matter, and easy to resolve locally. > Consider a caller which calls SSL_renegotiate.

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni > wrote: > > There is no "the name that is being verified". The Postfix SMTP client > accepts multiple (configurable as a set) names for the peer endpoint. This > may be the next-hop domain or the MX hostname, or a

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

On 19/04/18 18:31, David Benjamin wrote: > I might suggest conditioning it on the compile-time version of OpenSSL > headers. This is a common transition strategy for systems working > through ABI constraints. (In some systems, this is implemented as some > target SDK version.) This is exactly

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

On Wed, Apr 18, 2018 at 11:05:05AM -0400, Viktor Dukhovni wrote: > > What I can blame them for is being counter-productively pedantic. Forget the > RFC language, does what they're doing make sense and improve security or is > it just a pointless downgrade justified by RFC text lawyering? I'm

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 18, 2018, at 10:43 AM, Andy Polyakov wrote: > > It can either be a probe just to see if it's reasonable to demand it, or > establish a precedent that they can refer to saying "it was always like > that, *your* application is broken, not ours." Also note that

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> ... what does not make any sense to me is what Google is doing. Snatching > defeat from the jaws of victory by needlessly forcing clients to downgrade to > TLS 1.2. Is there a justification for this? It can either be a probe just to see if it's reasonable to demand it, or establish a

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> On Apr 18, 2018, at 10:12 AM, Andy Polyakov wrote: > > With this in mind, wouldn't it be more > appropriate to simply not offer 1.3 capability if application didn't > provide input for SNI? That's what Rich suggested, and it makes sense, but what does not make any sense

Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)

> When I link posttls-finger with the OpenSSL 1.1.1 library, I see: Just in case for reference, one can reproduce all this with 1.1.1 s_client. Below case is -starttls smtp -noservername. "Fun" part is that OU for the self-signed certificate reads "No SNI provided; please fix your client."