Re: [openssl-project] When to enable TLS 1.3
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-users> openssl-users> * Restrict TLS 1.3 support to just applications compiled openssl-users> against 1.1.1? A weak signal, but likely correlates at openssl-users> least somewhat with the application being ready. openssl-users> openssl-users> * Determine whether the application is likely to be compatible openssl-users> at runtime by looking at the provided configuration. Is SNI openssl-users> enabled? Is the certificate chain weird enough to break with openssl-users> TLS 1.3. Has the application turned off critical algorithms? Of those two, the second provides for a smoother transition to using TLSv1.3, all it might take is changing a configuration, getting a newer certificate with a more compatible chain, changing an engine module. Some of those may take some time (even purchasing a new cert, what do I know?), but still. If at all possible, the second choice seems like the better one. The only reason I can see for the first option is if there are things that cannot be detected in run-time that would cause the use of older protocols rather than TLSv1.3. I suspect a too early call of SSL_version might be one that's hard to cope with... openssl-users> * Do nothing, let the applications adapt or stick with older openssl-users> libraries? I don't see this as acceptable. Let's remember that 1.1.0 -> 1.1.1 is a *minor* upgrade, i.e. should be a drop-in backward compatible replacement. If that upgrade causes applications to suddenly stop working because we're force feeding them TLSv1.3, then we've failed that technical promise. If I was a user in that scenario, I'd be furious. openssl-users> * Something else? Making this a *major* upgrade, i.e. 1.2.0. openssl-users> We don't have much time before release, what do we do? If we can't resolve this, there is the option of delaying the release. The release strategy is clear on this: "This may be amended at any time as the need arises." (https://www.openssl.org/policies/releasestrat.html) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)
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 compiled > against 1.1.1? A weak signal, but likely correlates at > least somewhat with the application being ready. Applications get rebuild for all sort of reasons, I don't actually see this as a good signal at all. > * Determine whether the application is likely to be compatible > at runtime by looking at the provided configuration. Is SNI > enabled? Is the certificate chain weird enough to break with > TLS 1.3. Has the application turned off critical algorithms? > > * Do nothing, let the applications adapt or stick with older > libraries? I'm for keeping this as they are now. After the release some things might break. Applications will adapt. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] When to enable TLS 1.3 (was: Google's SNI hurdle)
> 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.) > > This is exactly what Richard proposed in this PR: > > https://github.com/openssl/openssl/pull/5945 So we should get back to what to do about the larger question. I am skeptical that just the compile-time header version is a sufficiently good indicator of which applications are prepared for TLS 1.3. For most applications integration into a new release involves recompiling the existing code and running some tests. If the tests don't cover interoperability with a sufficiently diverse set of remote peers, the application will be no more prepared for TLS 1.3 after compilation against OpenSSL 1.1.1 than it would have been had it been compiled against 1.1.0. So ideally we (collectively, the OpenSSL, Google, other TLS toolkits and service providers) will work to reduce friction so that more applications can use TLS 1.3 without running into any issues. 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 compiled against 1.1.1? A weak signal, but likely correlates at least somewhat with the application being ready. * Determine whether the application is likely to be compatible at runtime by looking at the provided configuration. Is SNI enabled? Is the certificate chain weird enough to break with TLS 1.3. Has the application turned off critical algorithms? * Do nothing, let the applications adapt or stick with older libraries? * Something else? We don't have much time before release, what do we do? -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 and offended, I am truly > truly sorry. Thanks. Much appreciated... Yes, there are other potential obstacles when enabling TLS 1.3 in applications not specifically designed for it. Some substantial, others less so. Without going into a length analysis, I think that most of the issues are minor, but authentication failure when an unexpected certificate appears with 1.3 that one would not see with 1.2 seems like a substantially more major hurdle, and one that sure seems avoidable. I hope it will be looked at more closely and in the not too distant future deployed less broadly (if at all). -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
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. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
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. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Potentially bad news on TLS 1.3 compatibility (sans SNI)
> 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 trade-offs, and are fair game for discussion. Ad hominem responses are entirely inappropriate, and an apology is due. David has done lots of good work, but we're all human, and the SNI ratchet is problematic for at least SMTP. I can legitimately be argued to be a poor tradeoff. Even in HTTP where the client ought to send SNI, if it does not, but would accept the default certificate (with e.g. TLS 1.2), the rationale for deliberately unusable certificates with TLS 1.3 does not look compelling, especially given the privacy leaks with SNI. -- -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/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 connect to. I think you would like to use > DANE instead. But I don't see DNSSEC or DANE getting wide adoption. NO. That's simply not the case, in fact I've contributed significantly to MTA-STS, and the use-case that fails here is NOT the DANE one (where SNI is already specified), but rather legacy WebPKI auth for SMTP. Please don't jump to conclusions or impute motives. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 sending SNI this will not change much. An alternative is that if you think the certificate should be trusted by the peer you don't select an anonymous cipher. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 the peer endpoint. This > > may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or > > some fixed hardcoded-name, or a mixture of these... > > Furthermore, with SMTP servers we can't be sure whether the peer even > tolerates SNI, it may decide that it has no certificate exactly matching the > client's guess, and hang up, even though the client would be happy with the > default certificate. > > I'm reluctant to start sending SNI in configurations that work fine without > SNI, and could well break when it is introduced. So if you're at all in > touch with the Gmail folks, please work with them to undo the ratchet in > question, at least SMTP MUST NOT suddenly stop yielding the expected default > certificate for lack of SNI. 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 think you would like to use DANE instead. But I don't see DNSSEC or DANE getting wide adoption. I currently see 4 type of connections for my outgoing mail in my postfix log: - Verified TLS connection: self-signed DANE - Verified TLS connection: DANE but with a valid certificate - Untrusted TLS connection: People who have a valid certificate for the hostname I connect to - Anonymous TLS: Using an anoymous cipher, yet having a valid certificate This is of course a very limited amount, only for what I send, but I think TLS for SMTP is already in a much better state now. I think in the end we should just enforce proper certificates. It would be nice that all those that do have a proper certificate are actually marked as "Verified", there really is no reason to say they are Untrusted. 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 SNI this will not change much. But I don't agree to Google's use of SNI, saying that if it supports TLS 1.3 that it must be modern software that should send an SNI. The library (OpenSSL) will support it, but that doesn't mean that application will set it, or that upgrading OpenSSL will suddenly make the appliation set it. I also don't see a relation between not sending SNI and not checking the certificate, you can perfectly write code that does not send an SNI but does proplery validate the certificate. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/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. Ditto. And sufficiently uncommon to not worry about. > A client which expects the session to be available immediately after the > handshake will also break. Sessions are not always offered by the server, clients already have to deal with this. > Or someone who listens to the message callback. Not worth worrying about. > Or someone who only installed CBC-mode ciphers in initialization. Not a problem, OpenSSL 1.1.1 has separate cipher controls for TLS 1.3 > Or just someone who calls SSL_version and checks that it is TLS1_2_VERSION. They can set the max version. ... The above are local edge cases. The SNI interoperability trap is random damage imposed by apparently capricious remote servers. I plead you reconsider this *particular* additional hoop for TLS 1.3 clients to jump through, just do whatever you did with TLS 1.2. If TLS 1.2 failed with SNI, fine do the same with TLS 1.3, if not then return the same chain. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 sub-domain wildcard, or > some fixed hardcoded-name, or a mixture of these... Furthermore, with SMTP servers we can't be sure whether the peer even tolerates SNI, it may decide that it has no certificate exactly matching the client's guess, and hang up, even though the client would be happy with the default certificate. I'm reluctant to start sending SNI in configurations that work fine without SNI, and could well break when it is introduced. So if you're at all in touch with the Gmail folks, please work with them to undo the ratchet in question, at least SMTP MUST NOT suddenly stop yielding the expected default certificate for lack of SNI. And just recompiling against OpenSSL 1.1.1 headers should not suddenly change behaviour. On the server side there needs to be some recognition of application context, with HTTP servers requiring SNI (where appropriate), but SMTP and other similar applications not doing so. I'd like to use TLS 1.3 in SMTP, even by default on a recompile or run-time relink with no code changes to explicitly enable TLS 1.3. But if servers are going to put up unnecessary roadblocks, TLS 1.3 is not going to get much traction. Please reconsider this particular ratchet (for at least SMTP). It *is* counter-productive. Not sure what OpenSSL should do at this point... :-( -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/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: > > 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 not sure I follow this. Why is the SNI value a guessing game? The client > that does not verify the certificate does not care what certificate it gets. > (This is why we still send something, rather than close the connection.) The > client that does verify a certificate, whether or not failures are fatal, > does not need to guess: use the name that is being verified. 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 some fixed hardcoded-name, or a mixture of these... -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
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 what Richard proposed in this PR: https://github.com/openssl/openssl/pull/5945 Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Problems with waiting for specific person to merge
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, it's the the first commiter that approves that is the one to merge it. I really have no problem that someone else merges my pull requests. Kurt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Problems with waiting for specific person to merge
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 rsalz> on the left side of the search box. Thanks... Now to remember to go there ;-) (I usually start from the notifications page and relatively seldom go to the PR list... it's a habit I probably should change) -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Problems with waiting for specific person to merge
>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 mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Problems with waiting for specific person to merge
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.Pierre> I think the reluctance to merge other committer's Matthias.St.Pierre> pull requests comes from the thought that it might Matthias.St.Pierre> appear impolite or that one does not want to Matthias.St.Pierre> interfere with the other's business. Personally, I Matthias.St.Pierre> don't have a problemat all if my pull requests are Matthias.St.Pierre> merged by others when I don't have the time to do Matthias.St.Pierre> it myself. When somebody notices that a pull Matthias.St.Pierre> request went stale after approval, I would suggest Matthias.St.Pierre> to ping the owner and give him/her a grace period Matthias.St.Pierre> of at least 24 hours to do it by it him/herself. Matthias.St.Pierre> After that it is perfectly ok to merge it. Yeah, I get that point, and you're right, there should be an attempt at a polite exchange first. In my defence, I had a quick chat with Emilia a couple of weeks ago, and it became clear that she has a busy period for the moment. Matthias.St.Pierre> For tickets owned by non-committers, my Matthias.St.Pierre> observation is that it is often not clear who will Matthias.St.Pierre> merge. I for myself follow the habbit of Matthias.St.Pierre> self-assigning a ticket as indication that I Matthias.St.Pierre> intend to do the merge. Sometimes others do it the Matthias.St.Pierre> same way, but it is not a general practice. Maybe Matthias.St.Pierre> we could make this a general pattern? This has actually varied a bit. What I've observed is that the first to approve is oftentimes the one that merges, unless something else is said (there have been some PRs where people have asked each other). Self assigning is a good habit... unless you have my tendencies, to *ahem* forget that you've self assigned something. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] Problems with waiting for specific person to merge
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 don't have a problemat all if my pull requests are merged by others when I don't have the time to do it myself. When somebody notices that a pull request went stale after approval, I would suggest to ping the owner and give him/her a grace period of at least 24 hours to do it by it him/herself. After that it is perfectly ok to merge it. For tickets owned by non-committers, my observation is that it is often not clear who will merge. I for myself follow the habbit of self-assigning a ticket as indication that I intend to do the merge. Sometimes others do it the same way, but it is not a general practice. Maybe we could make this a general pattern? Matthias > -Ursprüngliche Nachricht- > Von: openssl-project Im Auftrag von > Richard Levitte > Gesendet: Donnerstag, 19. April 2018 09:58 > An: openssl-project@openssl.org > Betreff: [openssl-project] Problems with waiting for specific person to merge > > 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 $DAYJOB may suck them into something > entirely different at any given time? I think that may be quite > unfair, and is bad for the project. > > So I think it's time we address this cultural thing (*), and also > perhaps take a closer look at PRs that have been left hanging for this > reason, and take it upon ourselves to help each other merge when we > notice that it doesn't happen on its own. > > Cheers, > Richard > > (*) It appears to be deep seated... there have been times when I knew > I was going to be away, and said that anyone is free to merge a PR I > submitted when it's approved, and it still didn't happen before I was > back and did it myself. smime.p7s Description: S/MIME cryptographic signature ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Problems with waiting for specific person to merge
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 $DAYJOB may suck them into something entirely different at any given time? I think that may be quite unfair, and is bad for the project. So I think it's time we address this cultural thing (*), and also perhaps take a closer look at PRs that have been left hanging for this reason, and take it upon ourselves to help each other merge when we notice that it doesn't happen on its own. Cheers, Richard (*) It appears to be deep seated... there have been times when I knew I was going to be away, and said that anyone is free to merge a PR I submitted when it's approved, and it still didn't happen before I was back and did it myself. --- Begin Message --- I see no reason not to merge this. It's been approved a long time ago, and the discussion that followed only clarifies the semantics, so... I know that @ekasper is quite busy elsewhere, so I'll merge now. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/openssl/openssl/pull/4955#issuecomment-382640850--- End Message --- ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
