Subject: [TLS] Controlling use of SHA-1

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 12:15:25 -0700

The current draft permits the use of SHA-1 in the certificate chain,
which gives SHA-1 a free pass indefinitely. Since we expressly forbid
the use of SHA-1 for signing in TLS itself, we can just permit clients
to include it in "signature_algorithms" and use that to determine
whether SHA-1 is acceptable.

That means that clients that want to disable SHA-1 (real soon now, we
promise), can signal that preference cleanly.

I've opened PR #317 for this, but the commit is probably more useful
to review, since I built this on top of ekr's client authentication
changes (to avoid messy rebases):

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 21 Oct 2015 12:17:44 -0700

I think this is the right answer and parallels what we are doing with PSS.

-Ekr

On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <[email-masked]>
wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 21 Oct 2015 19:45:38 +0000

I am in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not advertise SHA-1.

IMHO it would be best to not allow the server to send certs using any algorithms that don’t agree with signature_algorithms, as TLS 1.2 did. But this is a step in the right direction.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Wednesday, October 21, 2015 12:18 PM
To: Martin Thomson <[email-masked]>
Cc: [email-masked]
Subject: Re: [TLS] Controlling use of SHA-1

-Ekr

On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgithub.com%2fmartinthomson%2ftls13-spec%2fcommit%2f354475cf02819a9cc808457f2c09fdaeb1f82aa5&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ca50a95e365ed44d7a3bd08d2da4c67d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=cF5TaesUZE2CBZARx4UwZmdwV20K6b%2bRVn2hGIu3cOk%3d>

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ca50a95e365ed44d7a3bd08d2da4c67d7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=WPuilPjdjChwL4ym5xPuhH7Vho4qsPOM4KQWpkCr2t8%3d>

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 21 Oct 2015 19:56:09 +0000

On Wed, Oct 21, 2015 at 12:15:25PM -0700, Martin Thomson wrote:

> which gives SHA-1 a free pass indefinitely.

Forbidding the sending of SHA-1 chains was wrong last time we
discussed this at length, and remains wrong now.

Whether SHA-1 in the chain is used to make trust decisions is only
known to the client, and the server MUST NOT preempt that by denying
the client access to whatever chain it has on hand.

Each peer MUST try to send a chain that matches an advertised
signature algorithm if it has a choice of chains, but otherwise
MUST send whatever it has.

> promise), can signal that preference cleanly.

The clients can indeed not signal SHA-1 support, and SHOULD avoid
trusting SHA-1, but the server MUST still send whatever chain it
has and let the client decide.

> https://github.com/martinthomson/tls13-spec/commit/354475cf02819a9cc808457f2c09fdaeb1f82aa5

The final diff "hunk" is dejavu-all-over-again.  This text must
stay unchanged.

     indicated supported pairs, then it SHOULD continue the handshake by sending
     the client a certificate chain of its choice that may include algorithms
     that are not known to be supported by the client. This fallback chain MAY
    -use the deprecated SHA-1 hash algorithm.
    +use the deprecated SHA-1 hash algorithm only if the "signature_algorithms"
    +extension provided by the client permits it.
     If the client cannot construct an acceptable chain using the provided
     certificates and decides to abort the handshake, then it MUST send an
     "unsupported_certificate" alert message and close the connection.

So, no to the diff above.

-- 
	Viktor.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 21 Oct 2015 13:11:35 -0700

> MUST send whatever it has.

Do, or do not.  There is no try.

It's not like any of this is ambiguous in any way.

---

From: Dave Garrett <[email-masked]>
Date: Wed, 21 Oct 2015 19:52:01 -0400

I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE, but I think it's better than the alternative.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Wed, 21 Oct 2015 20:14:19 -0400

> the client access to whatever chain it has on hand.

Can we please just fix this issue properly and add an "any(0xFF)" value to the enum so clients can explicitly tell the server that they're capable of trusting certs directly (or is doing OE) and the hash is potentially irrelevant?

Note that the current proposed change does not break your use-case. Those clients can simply offer SHA-1 support indefinitely. Sure, they don't strictly support using SHA-1, but they support receiving certs using it, which is all the signal is really for.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Oct 2015 03:13:32 +0000

On Wed, Oct 21, 2015 at 08:14:19PM -0400, Dave Garrett wrote:

> Can we please just fix this issue properly and add an "any(0xFF)" value
> to the enum so clients can explicitly tell the server that they're capable
> of trusting certs directly (or is doing OE) and the hash is potentially
> irrelevant?

This forces a new signalling channel from TLS clients that need
this to their TLS library to enable this new "any" value.  Not an
API that's found in existing libraries or applications.  Previously
the TLS library would just let clients validate chains as they fit.

> Note that the current proposed change does not break your use-case. Those
> clients can simply offer SHA-1 support indefinitely. Sure, they don't
> strictly support using SHA-1, but they support receiving certs using it,
> which is all the signal is really for.

Yes, the signal "would" suffice, if it were practical to inject
it.  On the other hand, interposing on trust decisions for RFC 5280
chains is not the proper job of TLS.  And the chain the server has
may not get used by the client in full (the client might replace
some issuer certs with alternative certs for the "same" issuer).

So, just as before, why is the TLS server the proper vehicle for
hiding SHA-1 certs from potentially, but not necessarily PKIX
clients?  What's wrong with just having the various CAs no longer
issue SHA-1 certs, and the PKIX code in TLS libraries no longer
trusting SHA-1 certs by default?  Do we really need a third
counter-measure that exceeds the proper scope of TLS?

-- 
	Viktor.

---

From: Russ Housley <[email-masked]>
Date: Thu, 22 Oct 2015 03:27:04 -0400

I am also in favor of this change: it prohibits the server to send SHA-1 certs when signature_algorithms does not include SHA-1.

Russ

On Wed, Oct 21, 2015 at 12:15 PM, Martin Thomson <[email-masked]> wrote:

---

From: Rob Stradling <[email-masked]>
Date: Thu, 22 Oct 2015 08:42:51 +0100

On 22/10/15 00:52, Dave Garrett wrote:
> I'm in favor of this change as well. It annoys Viktor, as it changes the fallback in a way that isn't ideal for some cases that trust the cert directly or with OE,

IINM this also changes the fallback for servers that choose to include a 
PKIX trust anchor certificate in the Server Certificate message.

Lots of publicly trusted root certificates have sha1WithRSAEncryption 
signatures.  TLS clients typically don't verify these SHA-1 signatures, 
so there's no rush to remove them from trust anchor stores.

> but I think it's better than the alternative.

Why would it make sense to prohibit the sending of PKIX trust anchor 
certificates that have sha1WithRSAEncryption signatures?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Oct 2015 14:24:44 +0000

> PKIX trust anchor certificate in the Server Certificate message.

The signatures of trust-anchor (i.e. self-signed) certificates MUST
NOT be constrained by this proposal, even if the WG otherwise
chooses to step outside the proper scope of TLS into PKIX chain
validation.

Please note that the self-signature of the CAcert.org 4096-bit root
CA is MD5.

> certificates that have sha1WithRSAEncryption signatures?

It makes no sense to restrict the signatures of trust-anchors.  It
makes little sense to restrict the signatures certificates servers
can send to clients to be evaluated per the client's policy.

-- 
	Viktor.

---

From: Geoffrey Keating <[email-masked]>
Date: 22 Oct 2015 09:18:54 -0700

> chooses to step outside the proper scope of TLS into PKIX chain

I believe nothing is constrained by this proposal in the form you're
thinking.  That is, it's only if you have two versions of the root,
one with a requested algorithm and one without, that this proposal
comes into play.

At least, I think that's the intent.  It might help to clarify this in
the proposal.  It should be noted that the situation can become quite
complicated, for example it's possible that there might be one chain
which uses only SHA-2 which chains to one newer root, and another
chain which uses mostly SHA-1 and chains to a different older root.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2015 11:19:26 -0500

> can send to clients to be evaluated per the client's policy.

% a certificate that specifies a trust anchor MAY be omitted from the chain

The client cannot decide that the signature on the root cert the server
sent is bad, if the server does not send the root cert.

-Ben

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Oct 2015 10:30:33 -0700

> sent is bad, if the server does not send the root cert.

Yes, that was my thinking.

I expect that if a certificate is sent, then it might have to be
checked.  As opposed to the roots, which are rarely sent or checked.

Maybe it would help if Victor could describe the situation in which he
thinks that it would be appropriate to send a certificate that is
signed by MD5.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Oct 2015 17:45:51 +0000

> Maybe it would help if Victor could describe the situation in which he thinks
> that it would be appropriate to send a certificate that is signed by MD5.

Or where an application upgrades to a new library and expects EVERYTHING to work exactly as it used to, with no changes.

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2015 12:57:41 -0500

> Or where an application upgrades to a new library and expects EVERYTHING to work exactly as it used to, with no changes.

That one's actually not very hard -- in a system like FreeBSD ports or
NetBSD pkgsrc, the application and the library are separately maintained
within the whole tree, and when someone builds the application, they get
whatever version of the library happens to be in the tree at that time. 
The library can easily get upgraded without the application maintainer
noticing, and the automated systems are only likely to detect
compilation failure, not runtime behavior changes.

That is, the library update can be transparent to the end-user, who will
continue to expect normal functionality and expect everything to work.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Oct 2015 18:00:32 +0000

> continue to expect normal functionality and expect everything to work.

Should all applications suddenly start using TLS 1.3 without any changes?  Really?  Or should what *they used to do* just work as it was?  If that?  Suppose what they used to do is now considered bad practice?

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Oct 2015 18:12:35 +0000

> checked.  As opposed to the roots, which are rarely sent or checked.

The roots are sent more frequently than you imagine.  With DANE-TA(2)
they MUST be sent if the server's TLSA record nominates a self-signed
trust-anchor.  Further-more, OpenSSL sends whatever the administrator
puts in the server "chain file", it would be wrong for it to
selectively delete the configured certificates, and many systems
include the root CA in the chain file.

> thinks that it would be appropriate to send a certificate that is

The CAcert.org root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with CAcert.org
client cert chains, and provide client certs to the
mail.protection.outlook.com MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

The refusal to accept an MD5 self-signature is pedantic security
degradation.

-- 
	Viktor.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 22 Oct 2015 14:17:09 -0400

On Oct 22, 2015 2:00 PM, "Salz, Rich" <[email-masked]> wrote:
> Should all applications suddenly start using TLS 1.3 without any
changes?  Really?  Or should what *they used to do* just work as it was?
If that?  Suppose what they used to do is now considered bad practice?

Ideally, yes. Applications never cared about what was happening, but wanted
a "secure this channel" magic call.

It's particularly important when we want to hunt down and eliminate bugs.

---

From: Andrei Popov <[email-masked]>
Date: Thu, 22 Oct 2015 18:18:30 +0000

What if we just made an explicit exception for root cert hash algorithms and not constrained them by the client's alg list?
________________________________
From: Viktor Dukhovni
Sent: 10/22/2015 11:12 AM
To: [email-masked]
Subject: Re: [TLS] Controlling use of SHA-1

> thinks that it would be appropriate to send a certificate that is

The https://na01.safelinks.protection.outlook.com/?url=CAcert.org&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0kTNAt0ca9TAbtb1Gt5LanTfYajUCeKkuFZp59a9ljs%3d root is self-signed with MD5 and is sent as part of
the chain by various systems.  This self-signature is harmless,
but some systems pedantically disrupt the handshake in response.

For example, some Postfix clients are configured with https://na01.safelinks.protection.outlook.com/?url=CAcert.org&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=0kTNAt0ca9TAbtb1Gt5LanTfYajUCeKkuFZp59a9ljs%3d
client cert chains, and provide client certs to the
https://na01.safelinks.protection.outlook.com/?url=mail.protection.outlook.com&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=fKDA5Lyxn7S8P4BVFDD1mL1oyIzGYif5X2j4dH0NG80%3d MTAs which then force a downgrade to
cleartext by refusing to continue the handshake.

--
        Viktor.

_______________________________________________
TLS mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7ccd7915497f68419ab67208d2db0c61b7%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=OYsiJgPkphzBreBA9Uv0aKCyw2yMEaa2QGNInB41x%2bc%3d

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 22 Oct 2015 13:18:37 -0500

> Should all applications suddenly start using TLS 1.3 without any changes?  Really?  Or should what *they used to do* just work as it was?  If that?  Suppose what they used to do is now considered b…

If we (okay, not "we", library implementors) require explicit
application opt-in to TLS 1.3, the adoption rate is probably not going
to be very good.  So, yes, I think applications should start using TLS
1.3 without any changes.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Oct 2015 18:20:07 +0000

> If we (okay, not "we", library implementors) require explicit application opt-
> in to TLS 1.3, the adoption rate is probably not going to be very good.  So, yes,
> I think applications should start using TLS 1.3 without any changes.

And what about 0RTT?  Removed support for some crypto?  Various other semantic changes?

What you're really saying is "just like it always used to be, just better."

And I want a pony.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 22 Oct 2015 14:26:50 -0400

> > If we (okay, not "we", library implementors) require explicit
application opt-
> And what about 0RTT?  Removed support for some crypto?  Various other
semantic changes?

If you don't enable 0RTT support and ignore removed crypto, what breaks?
Most apps don't use renegotiation anyway?
> What you're really saying is "just like it always used to be, just
better."

Most applications want a simple API that hides all the complexities of TLS.
If OpenSSL had done that, then it would be easy to see how enabling 1.2
won't cause problems for those apps which said "you take care of it".

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 22 Oct 2015 21:38:30 +0300

On Thu, Oct 22, 2015 at 01:18:37PM -0500, Benjamin Kaduk wrote:
> > Should all applications suddenly start using TLS 1.3 without any changes?
> >  Really?  Or should what *they used to do* just work as it was?  If that?
> > Suppose what they used to do is now considered bad practice?
> 

As a note, I have personally seen bad security resulting from
application having to enable TLS versions.

I expect applications to start supporting TLS 1.3 with just upgrading
the crypto shared object, without even changing the application
executable.

Of course, features like 0-RTT won't work without application support,
but nothing existing uses those anyway.

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 22 Oct 2015 18:40:25 +0000

> Most applications want a simple API that hides all the complexities of TLS. If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't cause problems for those apps which said "you take care of it".

As someone with a long history of building, influencing, and using libraries and their API's, this is not easy.

Would you disable 0RTT because the earlydata might be replayed?  That would be the secure thing to do, so you make applications that want to use new features do extra work, ok. Would you disable AES-GCM because it's new, and perhaps it's an ARM-based application so the CPU cost is expensive? That's the insecure thing to do, isn't it?  Who makes that trade-off? SCSV?  SSLv2? Trust anchors?

I still want a pony.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 11:41:36 -0700

> Suppose what they used to do is now considered bad practice?

I would say anything they do that's good practice should keep working :)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 22 Oct 2015 11:43:32 -0700

> And what about 0RTT?  Removed support for some crypto?  Various other

So, I think we've agreed that using 0-RTT should require explicit action.
And similarly if you have required some crypto algorithm that TLS 1.3
doesn't support (or you don't support any of the new ones) it should
fail. However, if you are using a conceptually compatible subset of
TLS 1.2 (i.e., modern algorithms, no renegotiation),
then I would expect you to be able to drop in TLS 1.3 and have
it work.

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 22 Oct 2015 14:53:36 -0400

> On Oct 22, 2015, at 2:18 PM, Andrei Popov <[email-masked]> wrote:
> 

Yes, that would be substantially less bad.  I still don't see any compelling reason to shift chain validation policy from the verifying peer (typically client) to the subject (typically server).  The subject supplies its credentials good or bad, and the *verifier* enforces the right policy.

Indeed if we rely on servers never sending weak creds, clients might be lazy and vulnerable by not checking that they got strong creds.  The enforcement belongs in the verifier.

And yes, to repeat agreement with Andrei's specific point, exempting root-CA self-signatures would be substantially less bad than disallowing various signature algorithms globally.

-- 
	Viktor.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 23 Oct 2015 00:02:45 +0300

> On 22 Oct 2015, at 9:26 PM, Watson Ladd <[email-masked]> wrote:
> 
> 
> On Oct 22, 2015 2:20 PM, "Salz, Rich" <[email-masked] <mailto:[email-masked]>> wrote:
> >
> If you don't enable 0RTT support and ignore removed crypto, what breaks? Most apps don't use renegotiation anyway?
> >
> Most applications want a simple API that hides all the complexities of TLS. If OpenSSL had done that, then it would be easy to see how enabling 1.2 won't cause problems for those apps which said "you take care of it”.
> 
That is true only if your application’s client component and server component are using the same library. That is not guaranteed in a protocol. Specifically that is not the case with the web.

There are some version intolerant servers out there that will choke on seeing a TLS 1.3 ClientHello. If the client uses some library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that has TLS 1.3. All of the sudden your application is broken. On the web this means that some websites don’t work.  Do you live with the application being sometimes broken?  Do you make some downgrade dance? Hard question, and one that the application needs to answer. 

In any library it’s a major problem if an API call fails in the new version of the library where it would succeed in the old version. In a library implementing a protocol this could happen because of the network, because of middleboxes implementing their own version of “sanity” on the traffic, or because of peers that might have a different interpretation of the previous standard.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 22 Oct 2015 14:07:52 -0700

> a "secure this channel" magic call.

I think that this is conditionally true.  If you are using TLS 1.2
with reasonably modern practices, then getting TLS 1.3 should be easy.
However, if you are relying on MD5 working, or limiting cipher suites
to RC4, then expect some pain.

For NSS, we probably won't turn TLS 1.3 on by default straight away,
but once it is stable, I expect that we will.  Applications that use
the defaults will get 1.3 at that point and not have to worry about
breakage.

Of course, we will be careful not to use 1.3 if things aren't
configured correctly (PFS disabled = no 1.3, etc...) This might not be
easy to perfect, but I believe that this is a goal that is worth the
extra effort.

---

From: Bill Frantz <[email-masked]>
Date: Thu, 22 Oct 2015 14:49:47 -0700

On 10/23/15 at 2:02 PM, [email-masked] (Yoav Nir) wrote:

>That is true only if your application’s client component and 
>server component are using the same library. That is not 
>guaranteed in a protocol. Specifically that is not the case 
>with the web.
>
>There are some version intolerant servers out there that will 
>choke on seeing a TLS 1.3 ClientHello. If the client uses some 
>library (like OpenSSL) and you upgrade to OpenSSL 1.2.0 that 
>has TLS 1.3. All of the sudden your application is broken. On 
>the web this means that some websites don’t work.

This incompatibility cuts both ways. Another way of looking at 
it is that all of a sudden your website has lost viewers and you 
should fix your problem. Perhaps I am unusual, but if I go the a 
website that doesn't work, I usually conclude that I don't need 
to see that web site. My problem is too little time, meaning I 
don't want to bleep with things that don't work, not extra time 
to futz with different browsers to get things working.

Cheers - Bill

-------------------------------------------------------------------------
Bill Frantz        | Airline peanut bag: "Produced  | Periwinkle
(408)356-8506      | in a facility that processes   | 16345 
Englewood Ave
www.pwpconsult.com | peanuts and other nuts." - Duh | Los Gatos, 
CA 95032

---

From: Dave Garrett <[email-masked]>
Date: Thu, 22 Oct 2015 20:19:12 -0400

> What if we just made an explicit exception for root cert hash algorithms and not constrained them by the client's alg list?

+1

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 23 Oct 2015 04:33:58 +0000

On Thu, Oct 22, 2015 at 06:40:25PM +0000, Salz, Rich wrote:

> > Most applications want a simple API that hides all the complexities of
> > TLS. If OpenSSL had done that, then it would be easy to see how enabling
> > 1.2 won't cause problems for those apps which said "you take care of it".
> 

Binary compatibility is difficult, and requires maintaining legacy
versions of interfaces with cross-platform symbol versioning and
related magic that transcends the release engineering cycles
available to OpenSSL at this time.

That said, source compatibility is a fairly reasonable requirement.

By and large for applications doing simple things, OpenSSL remains
source compatible all the way from 0.9.5a to "master" (soon to be
1.1.0).  Postfix, which uses OpenSSL in a rather more sophisticated
way, has relatively minor adaptations to deal with source compatibility
changes from the 0.9.7 time-frame to the present (we've dropped
support for older OpenSSL versions that was present in earlier
Postfix releases, otherwise that would be 0.9.5 to the present).

Enabling TLS 1.2 (in OpenSSL 1.0.1) caused no fundamental problems
for Postfix, it largely continued to work as-is.  IIRC the padding
extension was needed in 1.0.1g to deal with interoperability with
some IronPort systems that had issues with large client HELLO
messages solved by padding.  The much larger list of ciphersuites
also caused pain with some rather dated Microsoft Exchange 2003
servers that were still in use.  But on the whole the transition
just worked, as it should have.

So recompiling a package against an OpenSSL that supports TLS 1.3,
and fixing occasional issues with now opaque data structures hidden
behind new accessors, should be sufficient for a largely unchanged
application to use TLS 1.3 with no explicit code changes to do so.

> I still want a pony.

I expect to report that Postfix works as-is when OpenSSL is released
with TLS 1.3.  This is not an unreasonable expectation.

If TLS 1.3 does not interoperate with opportunistic TLS clients
when servers are configured with pre-existing self-signed SHA-1
certificates, then IMHO the specification is broken.

If TLS 1.3 pig-headedly forbids sending non-root SHA-1 certs, and
OpenSSL with TLS 1.3 negotiates TLS 1.3 when a server has only a
CA-issued certificate signed with SHA-1, then OpenSSL is broken,
for it should then have worked around the specification brain-damage
by selecting TLS 1.2 (presumably the client still supports that).

I am perplexed that folks desperately want that server with that
SHA-1 cert to not be able to use TLS 1.3.  Surely, the decision to
not trust that cert (if certs are being checked at all) belongs in
the client.

Provided that weak self-signatures are not proscribed, I am resigned
to "come what may" if nobody else thinks that proper segregation
of duties is important, and that putting up some needless roadblocks
to TLS 1.3 use is the price of "progress".

-- 
	Viktor.

---

From: "Short, Todd" <[email-masked]>
Date: Fri, 23 Oct 2015 13:55:43 +0000

Fundamentally, it is up to the client (or server when doing Client Authentication) to choose whether or not to trust a received certificate chain.
I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker message digests), but “I’m not sure it’s a good idea” (SM) to force the issue in a new version of the protocol that is dependent on external specs (e.g. X.509) which permit those message digests.
If we want to promote TLSv1.3 and attempt to have faster adoption than TLSv1.2, we can’t shoot ourselves in the foot and not work with a large majority of servers out there still using old certificates.
Which by the way, do expire, and subsequently upon renewal, are signed with stronger message digests. The issue is with the old, ancient roots, that still use legacy message digest algorithms, and are less easy to update. But it can be done!
I think the onus is really on the library authors to validate the chain, but report anomalies such as SHA-1 in the chain, or a MD5-self-signed-root. The applications are then free to accept the chain or not. Chrome has already done this, and adding support to libraries to make this the default or easier to detect makes it that much easier to deprecate SHA1.
In summary, I’m in the SHOULD NOT use SHA-1 camp, rather than the MUST NOT.
--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Oct 23, 2015, at 12:33 AM, Viktor Dukhovni <[email-masked]<mailto:[email-masked]>> wrote:

As someone with a long history of building, influencing, and using libraries
and their API's, this is not easy.

I still want a pony.

--
Viktor.

---

From: Michał Staruch <[email-masked]>
Date: Fri, 23 Oct 2015 18:28:34 +0200

According to the CA/Browser Forum Baseline Requirements
<https://cabforum.org/baseline-requirements-documents/> after 1 January
2016 CAs MUST NOT issue any new Subscriber or Subordinate CA certificates
using SHA-1, so we shouldn't see any new certificates with SHA-1 after this
date.

Another thing is cost of SHA-1 collision attacks - currently it's at $100K
level (see the Freestart collision on full SHA-1
<https://eprint.iacr.org/2015/967> paper), so I think it's pretty much the
time when we should say that SHA-1 MUST NOT be used in upcoming TLS
versions.

On Fri, Oct 23, 2015 at 3:55 PM, Short, Todd <[email-masked]> wrote:

> Fundamentally, it is up to the client (or server when doing Client
> Authentication) to choose whether or not to trust a received certificate
> chain.
> I am all for deprecating SHA-1 (and MD-5 and MD-2, and other weaker
> message digests), but “I’m not sure it’s a good idea” (SM) to force the
> issue in a new version of the protocol that is dependent on external specs
> (e.g. X.509) which permit those message digests.
> If we want to promote TLSv1.3 and attempt to have faster adoption than
> TLSv1.2, we can’t shoot ourselves in the foot and not work with a large
> majority of servers out there still using old certificates.
> Which by the way, do expire, and subsequently upon renewal, are signed
> with stronger message digests. The issue is with the old, ancient roots,
> that still use legacy message digest algorithms, and are less easy to
> update. But it can be done!
> I think the onus is really on the library authors to validate the chain,
> but report anomalies such as SHA-1 in the chain, or a MD5-self-signed-root.
> The applications are then free to accept the chain or not. Chrome has
> already done this, and adding support to libraries to make this the default
> or easier to detect makes it that much easier to deprecate SHA1.
> // [email-masked]
> On Oct 23, 2015, at 12:33 AM, Viktor Dukhovni <[email-masked]>
> wrote:
>

-- 

Pozdrawiam | Best Regards

Michał Staruch | Information Security Officer

ul. Sienkiewicza 9, 65-001 Zielona Góra

[email-masked]

Find us on Bloomberg CKPL <GO>
 <https://cinkciarz.pl>

*Cinkciarz.pl Sp. z o.o.*

*Siedziba:* ul. Sienkiewicza 9, 65-001 Zielona Góra

*Biuro PL:* Al. Jerozolimskie 123A, 00-965 Warszawa

*Biuro UK:* The Broadgate Tower, 20 Primrose Street, London EC2A 2EW

*Biuro USA:* 401 North Michigan Avenue, Chicago, Illinois, 60611

*Sekretariat:* +48 726 666 655 | *Infolinia:* +48 68 410 99 50

[email-masked] | https://cinkciarz.pl

KRS 0000364722 | Kapitał zakładowy 23.263.500 zł

REGON 080465538 | NIP 9291830388

Audited by: Grant Thornton

Treść tej wiadomości zawiera informacje poufne, przeznaczone tylko dla
adresata. Udostępnianie, ujawnianie, powielanie, rozpowszechnianie bądź
powoływanie się na jakikolwiek jej fragment przez inne osoby jest
zabronione. W razie przypadkowego otrzymania tej wiadomości prosimy o
powiadomienie o tym nadawcy oraz trwałe jej usunięcie. Informacje zawarte w
tej wiadomości mogą być objęte tajemnicą zawodową lub chronione innymi
przepisami prawnymi. Nadawca nie bierze odpowiedzialności za jakiekolwiek
szkody spowodowane wirusem komputerowym przetransmitowanym w tej
wiadomości.  Poglądy i opinie przedstawione w tej wiadomości są wyłącznie
poglądami i opiniami jej autora i niekoniecznie reprezentują poglądy i
opinie firmy.

This is a confidential e-mail intended solely for the use of the entity or
the individual to whom it is addressed. Unauthorized publication, use,
dissemination or disclosure of this message, either in whole or in part is
strictly prohibited. If you have received this message in error please send
it back to the sender and delete it. It may also be privileged or otherwise
protected by work product immunity or other legal rules. The company
accepts no liability for any damage caused by any virus transmitted by this
e-mail. Any views or opinions presented in this e-mail are solely those of
the author and do not necessarily represent those of the company.

---

From: [email-masked] (Martin Rex)
Date: Fri, 23 Oct 2015 23:05:57 +0200 (CEST)

> available to OpenSSL at this time.

Binary compatibility is actually fairly easy.  We've been providing
it for several APIs on several platforms for the last 20 years.

What is a pain in the butt is backwards-incompatible _specifications_.
TLSv1.2 contains a few places of severe breakage, and dealing with
these in a backwards-compatible fashion is what is difficult.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 23 Oct 2015 23:27:00 +0200 (CEST)

> It's not like any of this is ambiguous in any way.

This is NOT about digitally_signed, which the server newly creates
himself, and therefore has a choice.

Very few servers, if any, can (or will) create their own server
certificate and chain certificates above on the fly during a TLS
handshake.  Instead, server's will have to choose their server
certificate & chain from whatever the server admin has previously
configured.

So similar to TLS extension SNI, the server can only use the signature
algorithms for guidance finding the best possible match for the clients
conveyed preferences.  Ultimately, it is up to the client to decide
whether to accept an trust the server's certificate chain anyway.

Even for a certificate chain with matching algorithms, the client
may decide to abort because it doesn't trust the issuer of the
server's certificate.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 30 Oct 2015 20:34:48 +0100

> to futz with different browsers to get things working.

Until you have to get a refund on a $500 purchase through such broken 
web server...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic