Re: [openssl-project] When to enable TLS 1.3

2018-04-19 Thread Richard Levitte
In message on Thu, 19 Apr 2018 19:16:04 -0400, Viktor Dukhovni said: openssl-users> But not all the friction can be eliminated, and likely not openssl-users> all providers can be persuaded to be more accommodating. openssl-users> Which leaves us with some difficult judgement calls: openssl-user

Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 07:16:04PM -0400, Viktor Dukhovni wrote: > > But not all the friction can be eliminated, and likely not > all providers can be persuaded to be more accommodating. > Which leaves us with some difficult judgement calls: > > * Restrict TLS 1.3 support to just applications c

[openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)

2018-04-19 Thread Viktor Dukhovni
> On Apr 19, 2018, at 1:48 PM, Matt Caswell 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.) >

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

2018-04-19 Thread Viktor Dukhovni
> 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 and offended, I am

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

2018-04-19 Thread Salz, Rich
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 and offended, I am truly truly sorry. ___

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

2018-04-19 Thread Salz, Rich
Sorry if I offended you. On 4/19/18, 3:23 PM, "Viktor Dukhovni" wrote: > 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.

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

2018-04-19 Thread Viktor Dukhovni
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote: > > David has pointed out valid use-cases. I think most use-cases will "just > work." We should document the known sharp edges. I am pointing valid use-cases that David has not taken into account, and conformance ratchets have cost/benefit t

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

2018-04-19 Thread Viktor Dukhovni
> 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 mailing list openssl-pro

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

2018-04-19 Thread Viktor Dukhovni
> 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 connect to. I th

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

2018-04-19 Thread Kurt Roeckx
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 sending

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

2018-04-19 Thread Kurt Roeckx
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 the peer endpoint. This > >

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

2018-04-19 Thread Salz, Rich
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 mailin

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

2018-04-19 Thread Viktor Dukhovni
> 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. Ditto. And sufficientl

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

2018-04-19 Thread Viktor Dukhovni
> 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 sub-domain wildcard, or > s

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

2018-04-19 Thread Viktor Dukhovni
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote: > > Consequently, opportunistic SMTP clients (or those using mandatory TLS, but > without > DANE where the SNI value is still a guessing game we did not play) won't get > TLS 1.3, until they start to make up some sort of SNI name. > > I'm

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

2018-04-19 Thread Matt Caswell
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 wh

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Kurt Roeckx
On Thu, Apr 19, 2018 at 09:58:26AM +0200, Richard Levitte wrote: > When someone with write access to the main repo makes a PR and it gets > approved, we usually wait for the person to do the final merge. This is also what we agreed to do a long time ago, including that for PRs of a non-commiter, i

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Richard Levitte
In message on Thu, 19 Apr 2018 12:57:39 +, "Salz, Rich" said: rsalz> rsalz> >Self assigning is a good habit... unless you have my tendencies, to rsalz> *ahem* forget that you've self assigned something. rsalz> rsalz> There's a built-in filter that says "find my PR's" It's just

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Salz, Rich
>Self assigning is a good habit... unless you have my tendencies, to *ahem* forget that you've self assigned something. There's a built-in filter that says "find my PR's" It's just on the left side of the search box. ___ openssl-project ma

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Richard Levitte
In message <9d1d9c5d9b0c4d54ae72d0759d0da...@ex13.ncp.local> on Thu, 19 Apr 2018 08:30:03 +, "Dr. Matthias St. Pierre" said: Matthias.St.Pierre> Speaking as one of the committer with $PAYROLL != Matthias.St.Pierre> "OpenSSL", I would like to add two remarks. Matthias.St.Pierre> Matthias.St

Re: [openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Dr. Matthias St. Pierre
Speaking as one of the committer with $PAYROLL != "OpenSSL", I would like to add two remarks. I think the reluctance to merge other committer's pull requests comes from the thought that it might appear impolite or that one does not want to interfere with the other's business. Personally, I do

[openssl-project] Problems with waiting for specific person to merge

2018-04-19 Thread Richard Levitte
When someone with write access to the main repo makes a PR and it gets approved, we usually wait for the person to do the final merge. This is perfectly fine to expect from us who are so called fellows, i.e. who are payed directly to work on OpenSSL... but to ask this of everyone else, when their