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

[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-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)

[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 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)

[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.)
> 
> 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)

[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 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 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-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 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 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)

[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 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)

[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 
> > 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)

[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 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 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 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)

[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 
> 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)

[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 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

[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, 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

[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
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

[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 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

[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.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

[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 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

[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 $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