Subject: [TLS] banning SHA-1 in TLS 1.3, a new attempt

From: Dave Garrett <[email-masked]>
Date: Sat, 10 Oct 2015 13:37:28 -0400

In light of completely unsurprising recent events [0], I think it's time to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3. Currently, it's allowed if needed by servers that have nothing better [1]. I propose we stop playing around and just prohibit it under TLS 1.3+. Implementations that can negotiate nothing better would be permitted to fall back to TLS 1.2 with the security restrictions currently in the draft [2] (which is still a concession I'd rather not make, but it's currently needed). I have submitted a PR [3] to this effect in order to have specific text to discuss here, though WG consensus and chair approval is of course required to change the current status.

Please note that TLS 1.3 is not coming out tomorrow, nor will its deployment be instant. By the time servers even decide to consider an upgrade, SHA-1 will be in an even less secure state than it already is.

To answer the obvious question: Prohibiting it in new versions reduces the risk of mistakes, draws a clear line where support is killed, and puts an actual impetus on PKI to transition faster. TLS 1.2 is potentially vulnerable, depending on configuration (nothing new there), but TLS 1.3 should be known to be secure in all valid configurations. The discussion to have with non-experts should not be about specific algorithms to pick and choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups, etc. etc.); we should be able to point at the current version and say "use this, not the old thing", or we can't expect it to be understood and taken seriously.

[0] https://sites.google.com/site/itstheshappening/
[1] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60
[2] https://tools.ietf.org/html/draft-ietf-tls-tls13-09#appendix-C.3
[3] https://github.com/tlswg/tls13-spec/pull/287

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 10 Oct 2015 19:44:04 +0200

On Sat, Oct 10, 2015 at 7:37 PM, Dave Garrett <[email-masked]>
wrote:

> In light of completely unsurprising recent events [0], I think it's time
> to reconsider the current consensus on how to deal with SHA-1 in TLS 1.3.
> Currently, it's allowed if needed by servers that have nothing better [1].

To be clear, the only thing that's allowed is SHA-1 in *certificates*.
It's forbidden in CertificateVerify.

-Ekr

> I propose we stop playing around and just prohibit it under TLS 1.3+.
> Implementations that can negotiate nothing better would be permitted to
> fall back to TLS 1.2 with the security restrictions currently in the draft
> [2] (which is still a concession I'd rather not make, but it's currently
> needed). I have submitted a PR [3] to this effect in order to have specific
> text to discuss here, though WG consensus and chair approval is of course
> required to change the current status.
>
> Please note that TLS 1.3 is not coming out tomorrow, nor will its
> deployment be instant. By the time servers even decide to consider an
> upgrade, SHA-1 will be in an even less secure state than it already is.
>
> To answer the obvious question: Prohibiting it in new versions reduces the
> risk of mistakes, draws a clear line where support is killed, and puts an
> actual impetus on PKI to transition faster. TLS 1.2 is potentially
> vulnerable, depending on configuration (nothing new there), but TLS 1.3
> should be known to be secure in all valid configurations. The discussion to
> have with non-experts should not be about specific algorithms to pick and
> choose (RC4, MD5, SHA1, EXPORT ciphers, non-AEAD, non-PFS, weak DH groups,
> etc. etc.); we should be able to point at the current version and say "use
> this, not the old thing", or we can't expect it to be understood and taken
> seriously.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 10 Oct 2015 23:28:28 +0300

> It's forbidden in CertificateVerify.

Isn't using it in certificates precisely more dangeous than using it in
CertificateVerify (especially with TLS 1.3)?

(Not that using it in CertificateVerify is a good idea).

Also, AFAIK, TLS 1.3 won't be published this year, so by the time it is
published, one can't get SHA-1 certs from public CAs anyway (or if you
can, those don't work reliably anyway).

-Ilari

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Oct 2015 20:59:09 +0000

> CertificateVerify (especially with TLS 1.3)?

So long as SHA-1 self-signatures are still tolerated in root or
self-signed end-entity certificates, I have no objection to TLS
1.3 specifying that a certificate signed with SHA-1 is not trusted
even when issued by a trusted issuer.

However, we *must* be careful about what obligations we impose on
a client or server that encounters a certificate chain in which
some certificate which is not self-signed uses a SHA-1 signature.
It would be a big mistake to mandate fatal or even warning alerts
or closing the connection.  Rather, the required outcome is that
the chain is simply not trusted.  

Whether *that* in turn leads to a connection termination depends
on whether verification is required.  Opportunistic clients, or
servers that solicit optional client certificates need to be able
to continue despite the untrusted chain, and do what they do in
the absence of a peer certificate or when the peer certificate has
accceptable signatures, and and yet is still untrusted (or peername
does not match, ...).

So if the draft language for 1.3 essentially only prohibits *trusting*
SHA-1, but does not prohibit the *presence* of SHA-1 in the peer's
chain, I think that should be fine.

I don't want to see client's or servers hanging up just because a
peer presents a SHA-1 chain that would have been simply ignored
had it been SHA2-256 instead.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 10 Oct 2015 17:02:54 -0400

> (Not that using it in CertificateVerify is a good idea).

You can take all the time you need to forge something in a certificate chain (before expiry time), but to forge CertificateVerify you'd need to do it on the fly. Really dangerous vs. somewhat dangerous doesn't matter much here, though.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Oct 2015 21:10:46 +0000

> had it been SHA2-256 instead.

In particular pull request 287 breaks opportunistic TLS and *must*
not be adopted as-is.

It needs to allow SHA-1 chains to be sent when that's all that's
available.  The onus to not trust such chains is on the peer.  Some
peers may continue with the handshake despite the untrusted chain.
They may, for example, have pinned the leaf certificate and not
give a hoot about any of the signatures.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 10 Oct 2015 17:11:56 -0400

> had it been SHA2-256 instead.

Yes, to all points above. I feel like self-signed certs should have to use SHA-256 too, but mandating that doesn't get us that much.

The current PR is a bit too general; will need revision to handle all cases. I'll of course change it to accommodate concerns that come up in discussion here. Note that opportunistic encryption is weird and getting the whole document to be perfect for it might not be entirely doable, as OE needs to tolerate more fuzziness than the main spec should allow.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Oct 2015 21:19:30 +0000

On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:

> Note that opportunistic encryption is weird and getting
> the whole document to be perfect for it might not be entirely doable, as
> OE needs to tolerate more fuzziness than the main spec should allow.

Unfortunately requirements in the base TLS document end up "set in
stone" in software implementations, and then break opportunistic
TLS in ways application software can't work around.

So while the UTA TLS BCP can write requirements that exclude
opportunistic security, the TLS specification does not have
that liberty.

In this case the solution is simple enough.  DO NOT prohibit
the exchange of certificate chains with SHA-1 in them.  Just
prohibit *trusting* their content.

We alredy have language to allow servers and client to send
"last-resort" chains that don't match the peer's advertised supported
algorithms.  This suffices.

The necessary changes are then MUCH simpler than the current pull
request 287.

    * Prohibit advertising SHA-1 in the supported algorithms list,
      (except as needed for TLS 1.2 compat, ...)

    * Prohibit trusting SHA-1 when found in certificates that are
      not self-signed.

That's it.  A lot less work.  SHA-1 is no longer trusted, but does
not impede interoperability when certificates are largely useless
baggage.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 10 Oct 2015 18:46:47 -0400

> TLS in ways application software can't work around.

I do agree with rewording the text in question to deal with this better, but honestly, OE & AE are directly opposed concepts. I'd much rather write almost everything assuming the goal is properly authenticated encryption, and have a separate section dedicated to opportunistic encryption stating that its implementation requires ignoring many of the hard requirements TLS has with regard to authentication. Trying to subtlety allow for AE & OE in all the same text might give us a more fragile specification where accidentally screwing up authentication is easier. OE can be useful, but it's the exception, not the rule; giving AE too much wiggle-room could be dangerous. (when it's explicitly requested, e.g. TOFU with raw public keys, that's a different discussion)

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 02:35:16 +0000

On Sat, Oct 10, 2015 at 06:46:47PM -0400, Dave Garrett wrote:

> I do agree with rewording the text in question to deal with this better,
> but honestly, OE & AE are directly opposed concepts. I'd much rather write
> almost everything assuming the goal is properly authenticated encryption,
> and have a separate section dedicated to opportunistic encryption stating
> that its implementation requires ignoring many of the hard requirements
> TLS has with regard to authentication.

Sorry that works for the UTA BCP, but *cannot* work the TLS protocol
specification.  The TLS protocol cannot and SHOULD NOT make any
assumption about the client's security model, which can be:

    * PKIX with Web PKI public CAs
    * DANE-TA(2) with private CAs trusted via DNS
    * DANE-EE(3) (if you like server-side pinning via DNS).
    * RFC7250 bare public keys with DANE "3 1 1" bindings.
    * RFC7250 bare public keys with some other out-of-band keying
    * Trust on first use with leaf certificate pinning.
    * GSSAPI with channel binding
    * Unauthenticated opportunistic TLS.
    * ...

It is not appropriate for this WG to be narrowly focused on just
the first security model, which is certainly important, but not
to the exclusion of the rest.

> Trying to subtlety allow for AE &
> OE in all the same text might give us a more fragile specification where
> accidentally screwing up authentication is easier. OE can be useful, but
> it's the exception, not the rule; giving AE too much wiggle-room could be
> dangerous. (when it's explicitly requested, e.g. TOFU with raw public
> keys, that's a different discussion)

There is no subtlety getting in the way of not deprecating trust
in SHA-1, with a tiny bit of care it can be done generally without
breaking any of the use cases.

If the base protocol is bifurcated into many different use-cases,
implementations won't handle all the cases correctly.

This is not difficult, it just requires not forgetting that there's
more than one way to do (or not do) authentication, and that the
TLS protocol needs to remain largely agnostic of the authentication
model.  Just deliver the available credentials to the peer, and
let the peer decide what to do.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sat, 10 Oct 2015 23:00:30 -0400

> let the peer decide what to do.

It's the "or not do" that's the issue, not the other ways to do authentication that I'm concerned about. As I said, it looks like we can word this properly in a way that works for everyone. I just feel like the best way to cover the OE case fully is to address it in a separate section, explicitly, rather than (just) tweak wording to accommodate it. Even TOFU is more straightforward than OE, because at least with that it always follows basically the same pattern. OE requires you take what would normally be a blatant catastrophic error, but wave a wand and say it's OK for this separate use case. That may be true, but that doesn't make it any less of a blatant catastrophic error when that's not the case. I'm worried about having these not be completely distinct for the same reason you don't put a self-destruct button next to a light switch, no matter how well labeled. ;)

Also, I want the spec to anticipate some peers being incredibly stupid and avoid making it easy to mess things up.

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 03:22:52 +0000

On Sat, Oct 10, 2015 at 11:00:30PM -0400, Dave Garrett wrote:

> It's the "or not do" that's the issue, not the other ways to do
> authentication that I'm concerned about.

Concern is appropriate and healthy, and nevertheless the requirement
to not focus too narrowly remains.  For example a client doing
GSSAPI with channel-binding and ignoring TLS certificates is
essentially opportunistic viewed narrowly at the TLS layer, since
it may well accept (and ignore) whatever certificate chain is sent
its way.

> As I said, it looks like we can word this properly in a way that works
> for everyone. I just feel like the best way to cover the OE case fully is
> to address it in a separate section, explicitly, rather than (just) tweak
> wording to accommodate it.

Separate (and thus possibly conflicting) language only as a last
resort when a single specification is simply not possible.  Most
of TLS is trust model agnostic, so these differences should not
matter in most or perhaps the entire specification.

> Even TOFU is more straightforward than OE, because at least with that it
> always follows basically the same pattern.

Not when TOFU pins just the public key in the leaf cert.  Nothing
about the chain is then relevant, and the same SHA-1 questions are
out of scope.

> OE requires you take what would normally be a blatant catastrophic error,
> but wave a wand and say it's OK for this separate use case. That may be
> true, but that doesn't make it any less of a blatant catastrophic error
> when that's not the case.  I'm worried about having these not be completely
> distinct for the same reason you don't put a self-destruct button next to
> a light switch, no matter how well labeled.  ;)

TLS is silent on the trust model.  It makes Web PKI, DANE, TOFU
and OS/OE all equally possible.  The peer gets the TLS credentials,
the rest is up to the peer.

> Also, I want the spec to anticipate some peers being incredibly stupid
> and avoid making it easy to mess things up.

Web PKI authentication is specified in other IETF specifications
(RFC5280, RFC6125, ...).  TLS just sends the rockets up, and it is
not the job of TLS to care where they come down. :-)

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 05:08:41 +0000

On Sun, Oct 11, 2015 at 12:33:33AM -0400, Dave Garrett wrote:

> https://github.com/tlswg/tls13-spec/pull/287
> 
> PR updated with some revisions. Please take a look at some point and tell me what you think.

Still problematic, by changing more text than necessary.  The following
is wrong and should not be added.

    Just after which is largely fine (I would carve out an explicit
    exception for self-signatures which are a matter of data format
    necessity not trust):

	"Endpoints negotiating use of TLS 1.3 MUST NOT trust any
	signature that uses any of the deprecated hash algorithms
	(MD5, SHA-1, & SHA-224)"

    You add the incorrect:

	or send any certificate relying on any deprecated hash to
	its peer.  (see {{server-certificate}})

This is still the same problem as before.  The fix is to just as
before say no such thing, each peer sends something with a known
supported algorithm if it can, or whatever otherwise it has if it
can't.  Indeed with SNI, sending the right certificate (matching
SAN) takes precedence over any considerations of algorithms.  If
the none of the certificates with the right SAN have supported
algorithms, send one with an unsupported algorithm and let the peer
decide.

At which point, the next change is not needed:

    -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.
    +the client a certificate chain of its choice that MAY include algorithms
    +that are not known to be supported by the client.

For SHA-1 can still be sent, all that changes is that its in
signatures is no longer trusted, (but tolerated in self-signatures
which are not relevant in evaluating trust).

At which point we get to (removed original text elided, just
unchanged and new text below):

    If the client cannot construct an acceptable chain using the provided
    +certificates and decides to abort the handshake, then it MUST send a
    +fatal alert message and close the connection. If the chain is untrustworthy
    +because a certificate cannot be parsed correctly or due to use of a
    +deprecated hash algorithm (MD5, SHA-1, & SHA-224), then it SHOULD produce
    +a "bad_certificate" alert; otherwise it MUST produce an
    +"unsupported_certificate" alert.

It is simply wrong to require any particular reaction to an untrusted
chain.  Elements of the chain may expired, contain unknown (more
modern?) algorithms, and yet the handshake can continue in trust
models which don't need the problematic portion of the chain.

TLS does not mandate a trust model, it supports Web PKI trust more
directly than other models, but that's as far as it goes.

TLS can say that certificates with SHA-1 are no longer to be trusted.
Some such intermediate certificates sent by a peer may not even
end up in the (alternative) chain the verifier builds.  Or the
verifier may not validate any certificate chain at all.

    +Servers supporting both TLS 1.2 and TLS 1.3 MAY negotiate TLS 1.2 with
    +support for SHA-1 hashes, however servers MUST NOT downgrade to use an
    +older version in response to a TLS 1.3 client offering support for only
    +deprecated or unsupported hashes. All clients offering TLS 1.3 are REQUIRED
    +to offer support for at least one hash/signature pair which is not deprecated
    +(see {{signature-algorithms}}).

This is fine, and applies to TLS PRFs, ... but the certificate
chain can still contain (untrusted) SHA-1 signatures even with TLS
1.3.

    +MD5 hashes MUST NOT be used in any certificate in any TLS version, and any
    +implementation MAY reject any such certificate, without further inspection.

Again this is simply too strong.  Just like SHA-1, MD5 is not
trusted.  Its presence MUST NOT terminate the handshake, mandating
this at the TLS layer is a layer violation.  Trust is an application
layer problem.

Also the below is not appropriate:

    +-  Have you ensured that certificate chains using SHA-1 or SHA-224
    +  are only used with TLS 1.2 or older, or are prohibited completely?
    +

And this:

    +-  When the client has requested a server certificate, but no
    +  suitable certificate chain is available, do you correctly send a
    +  valid fallback chain using whatever TLS 1.3 permitted algorithms
    +  are necessary, instead of immediately aborting the connection?
    +

The fallback chain can contain anything at all.  CRC-32 if need
be.  Only SHA2-256, equivalent or better is to be trusted, but
that's a decision for the next layer up.

This pull request needs to simply specify that digest algorithms
other than SHA2-256 and SHA2-384 (plus any speficified in future
RFCs as sufficiently strong) are to be trusted by default.

Some clients may accept GOST signatures, that's a local matter for
those clients.  And we may yet see some subset of SHA3-256, SHAKE256,
Blake2, ... in certificates.

This draft deprecates trust in SHA-1, and restates non-trust of
MD5.  While clarifying that presence of either in certificates does
not constitude a malformed protocol message, and does not automatically
lead to fatal handshake errors.  Rather, when seen outside of
self-signatures in certificates needed to construct the complete
chain, these algorithms typically cause chain verification to fail,
which may in turn cause the handshake to be aborted for lack of
trust, not because of deprecated signature algorithms in the
certificate chain.

Is this clear yet?

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 01:53:34 -0400

> Is this clear yet?

It's clear, but we disagree on a few points here.

> algorithms, send one with an unsupported algorithm and let the peer

From a perspective to get it to work with the bare minimum needed, it's excessive. From a perspective of killing SHA-1 wherever viable, it is not. Any continued legitimate allowance of a deprecated hash perpetuates other possible continued allowances, even if the one in question is viable under some specific circumstance.

The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the exception of self-signed roots. This exception does not rely on the hash, as the whole cert is what's trusted, so this wording is fine. In fact, two endpoints exchanging certs using SHA1 with intent to directly trust certs is allowed with this wording. Shots-in-the-dark using SHA1 from general-purpose servers are not. I think you wish to allow this last case; I do not.

> models which don't need the problematic portion of the chain.

If the trust model doesn't need the problematic portion of the chain, then the chain is not trustworthy and this does not apply. Also note that it is merely saying that _if_ the client chooses to abort the handshake, that _then_ it must alert and abort, and then specifies which abort should be used. If the client does not decide to abort the handshake, then the _entire_ portion above is not applicable (no abort, because acceptable in its trust model, therefor no alert for the trustworthy chain), which is exactly what you're requesting.

> chain can still contain (untrusted) SHA-1 signatures even with TLS

Yes. The certificate list can contain untrusted stuff, but the whatever it builds out of that to trust cannot rely on it at any point. (e.g. can trust a chain with a root w/ SHA1 or directly trust such a cert, but not a link with a SHA1 sig)

Also note, that I initially was OK with considering downgrade as described above, however I feel like there's downgrade attack potential if that's allowed (especially without further specification).

> this at the TLS layer is a layer violation.  Trust is an application

It does not mandate termination; that's a "MAY". It says it "MUST NOT be used". A client could still accept it, if it really had to, so long as it's trusting the cert and not using the MD5 sig.

Again, show no quarter. Even the slightest implication that MD5 is valid in any scenario involving a TLS 1.3 endpoint is too much at this point.

[...]
> be.

No. It's not just a matter of what can be trusted, but also a matter of what should be considered acceptable. TLS has a lot of crippling problems because they get ignored. Nobody complained about SS2 CLIENT-HELLOs for 20 years, so we _still_ have to allow accepting them for TLS 1.0-1.2 connection attempts. If your goal is to truly phase out obsolete junk, you have to put pressure on it everywhere viable.

> Blake2, ... in certificates.

Yes. The goal here is blacklisting not whitelisting.

> trust, not because of deprecated signature algorithms in the

The text still has the client making the final call on server cert chains in all instances.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 02:01:59 -0400

On Sunday, October 11, 2015 01:53:34 am Dave Garrett wrote:
> If the trust model doesn't need the problematic portion of the chain, then the chain is not trustworthy and this does not apply.

Sorry, follow-up to fix a rather critical typo from a double negative. The "is not trustworthy" was meant to be "is not untrustworthy". If the trust model doesn't need a part to trust the peer, then it's not untrusted; it's irrelevant. The overall chain can be trustworthy regardless of what's in parts it doesn't care about.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Sun, 11 Oct 2015 10:03:35 +0300

On Oct 11, 2015, at 8:53 AM, Dave Garrett <[email-masked]> wrote:

> From a perspective to get it to work with the bare minimum needed, it's excessive. From a perspective of killing SHA-1 wherever viable, it is not.

I don’t think killing SHA-1 wherever viable should be a goal of this document. A certificate is a credential. It can be used in multiple protocols, standard and proprietary. Whether the certificate is trusted or not is up to the relying party regardless of what protocols that relying party uses. It is not for the TLS spec to dictate what properties a certificate should have, except when those properties make a difference for the protocol. So if we’re removing DSA from the spec, and have not yet standardized EdDSA signatures, it makes sense to require that the public key (not the signature!) in the certificate be either RSA or ECDSA. I don’t think it’s reasonable to require stuff that doesn’t enter the protocol.

> Any continued legitimate allowance of a deprecated hash perpetuates other possible continued allowances, even if the one in question is viable under some specific circumstance.
> 
> The goal I'm aiming for is SHA-1 being restricted to TLS 1.2

And assuming that TLS 1.3 has better security than TLS 1.2, how does this goal help security on the Internet?

We are not in charge of the Internet. We are only engineering some protocols that we hope the implementers will find useful. The industry *is* moving away from signing certificates with SHA-1, but that decision is being made elsewhere.

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 13:04:43 +0000

> > If the trust model doesn't need the problematic portion of the chain,
> > then the chain is not trustworthy and this does not apply.
>
> Sorry, follow-up to fix a rather critical typo from a double negative.
> The "is not trustworthy" was meant to be "is not untrustworthy". If the
> trust model doesn't need a part to trust the peer, then it's not untrusted;
> it's irrelevant. The overall chain can be trustworthy regardless of what's
> in parts it doesn't care about.

Yes, of course.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 15:24:03 +0000

> It's clear, but we disagree on a few points here.

It is important to keep in mind that the TLS protocol specification
has a reasonably well defined scope and must not intrude on matters
that lie outside that scope.

In particular, the TLS 1.3 protocol, when not performing PSK
resumption, carries a sequence of "certificates" whose first element
(possibly in fact a bare public key) signs the protocol key exchange.

The protocol tries to be helpful by providing certificates that
the peer will understand.  Therefore, the peer's list of supported
signature algorithms, whose primary purpose is to negotiate a
mutually supported PRF, is overloaded to help in certificate chain
selection.  When multiple choices of certificate chain are available
(quite rare at present) to a peer, "the best" one can be selected.

Beyond that however, it is not the TLS protocol's job to preempt
a peer's decision as to whether a given sequence of "certificates"
is trustworthy or even well formed.  That responsibility falls on
related higher-level protocols (PKIX 5280, Peer name checks RFC
6125, DANE 6698 as imminently updated by RFC 7671).

> From a perspective to get it to work with the bare minimum needed, it's
> excessive.  From a perspective of killing SHA-1 wherever viable, it is not.

Is is not appropriate mission for the TLS WG to launch a wider
anti-SHA1 crusade.  The TLS WG just needs to just avoid SHA-1
problems in the TLS protocol itself (PRFs, ...).  Avoiding SHA-1
in PKIX is outside this group's purview.

Yes, libraries that implement both TLS and PKIX and provide
applications with active-attack resistant "secure channels" will
should avoid trusting SHA-1 in PKIX, and I'm fine with a narrow
statement that the peer chain verification code in such libraries
should not trust SHA-1 issued certificates when negotiating TLS
1.3.  However the TLS specification MUST NOT preempt that verifier's
responsibility at the supplicant.

> Any continued legitimate allowance of a deprecated hash perpetuates other
> possible continued allowances, even if the one in question is viable under
> some specific circumstance.

See above, no crusades.

> The goal I'm aiming for is SHA-1 being restricted to TLS 1.2, with the
> exception of self-signed roots.

A lofty goal, but one that thoroughly exceeds the scope of the TLS
protocol.  SHA-1 must also be allowed in non-root certs, provided
the peer does not trust them (possibly does not need them at all).
This is something only the peer can know.

> In fact,
> two endpoints exchanging certs using SHA1 with intent to directly trust
> certs is allowed with this wording. Shots-in-the-dark using SHA1 from
> general-purpose servers are not. I think you wish to allow this last case;
> I do not.

I'm afraid this wish exceeds the proper scope of what the TLS
protocol can properly specify.

> If the trust model doesn't need the problematic portion of the chain, then
> the chain is not trustworthy and this does not apply.

This decision fundamentally belongs on the verifier side, and
therefore, it is NOT up to the sender to make it, nor is incumbent
on the verifier to reject the handshake because the chain sent
contains certificate with some algorithm it does not support if it
ends up not needing (to trust or use) those certificates.

> Also note that it
> is merely saying that _if_ the client chooses to abort the handshake, that
> _then_ it must alert and abort, and then specifies which abort should be
> used. If the client does not decide to abort the handshake, then the
> _entire_ portion above is not applicable (no abort, because acceptable in
> its trust model, therefor no alert for the trustworthy chain), which is
> exactly what you're requesting.

We already know what verifiers should do when they don't trust a
peer's credentials.  Nothing new applies when that's due do an
unsupported signature algorithm.

> Yes. The certificate list can contain untrusted stuff, but the whatever
> it builds out of that to trust cannot rely on it at any point. (e.g. can
> trust a chain with a root w/ SHA1 or directly trust such a cert, but not
> a link with a SHA1 sig)

This is something we agree on, so the pull request needs to limit itself
to *exactly* this.  Any trusted chain constructed by a TLS 1.3 peer cannot
contain issuer->subject links that employ SHA-1 signatures.

If you narrowly say just this, without making any other changes, I'm
on board.

> It does not mandate termination; that's a "MAY". It says it "MUST NOT be
> used". A client could still accept it, if it really had to, so long as
> it's trusting the cert and not using the MD5 sig.

Well, this "MAY" is in fact used incorrectly in Schannel, which
aborts connections with opportunistic TLS SMTP clients that present
client certs that include CAcert's MD5 self-signed root.

It aborts in the TLS library, rather than in the application
verification layer (which is opportunistic and allows anonymous
clients and otherwise unauthenticated clients).  This language
leads to breakage, and does not belong in specification.

It should maximally say that MD5 is untrusted, and should not
suggest that seeing MD5 in the peer's handshake cert chain is
sufficient grounds to immediately abort.

> Again, show no quarter. Even the slightest implication that MD5 is valid
> in any scenario involving a TLS 1.3 endpoint is too much at this point.

No religious zeal.  It is counter-productive.  The client in the
above example is forced to send in the clear, that's a self-imposed
downgrade from unauthenticated TLS to cleartext.  Is that better?

> No. It's not just a matter of what can be trusted, but also a matter of
> what should be considered acceptable.

I did not say that CRC-32 is acceptable for trusted signatures.
It would merely not be sufficient grounds to abort a connection just
because a peer sent a certificate with that in its signature (if
there hypothetically was a PKIX OID for a signature algorithm like
that).

Which again points out that signatures in X.509 are PKIX not TLS.
It is not the job of TLS to overreach.

> TLS has a lot of crippling problems
> because they get ignored. Nobody complained about SS2 CLIENT-HELLOs for
> 20 years, so we _still_ have to allow accepting them for TLS 1.0-1.2
> connection attempts. If your goal is to truly phase out obsolete junk,
> you have to put pressure on it everywhere viable.

Remove junk from TLS.  Clients that use TLS with PKIX, can avail
themselves of any junk cleanups that happen in PKIX and the libraries
that provide both TLS and PKIX.

We have a means to narrowly specify that TLS 1.3 PKIX profiles
should not trust SHA-1 signatures, we should say that and move on.
No religious zeal or overreach.

Clients that don't do PKIX at all, will then break needlessly
and possibly downgrade to cleartext.

> > MD5.

I am fine with non-trust.  I object to any and all requirements to
exclude these from TLS certificate messages presented to peers, or
to reject handshakes in which such messages are received.  If the
certificates presented are critical for the peer's trust decision
and trust is required to complete the handshake, *then* the handshake
breaks.  No new mandate to object to these algorithms in the peer's
chain based solely on their presence.

> > While clarifying that presence of either in certificates does
> > not constitute a malformed protocol message, and does not automatically

Not as written.  It needs to be clear that clients MUST NOT *trust*
these algorithms, and that's it.  If trust is required the connection
ends with a fatal alert.  If trust is not required, or the certificates
in question end up not used in whatever chain is ultimately trusted,
then the handshake continues.

TLS needs to do *its* job flawlessly, but not overreach.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 13:24:36 -0400

> in PKIX is outside this group's purview.

Every time something is "someone else's problem", it is ensured that the problem will not be properly fixed. Security is only as strong as the weakest link in the chain, and thus I don't believe a philosophy of complete separation of roles is realistic, especially in a world where upgrades and fixes are still deployed slowly and badly.

> See above, no crusades.

Calling the goal of phasing out known-bad features a "crusade" is not really helpful. I'm perfectly fine with stating that SHA-1 is reasonable to allow in areas where it needs to be for continued transition. It, however, should require justification to keep allowance rather than to remove.

> SHA-1 must also be allowed in non-root certs, provided

If we consider the certificate authenticated cipher suite scenario within TLS to expect this to be the common case, then that gives the false impression that admins don't "have" to upgrade because they're "usable". Assuming expertise is not safe. Servers should be sending certs using SHA256 or better. If it can't do that, then that needs to be fixed as a prerequisite. The alternative is a TLS implementation that tolerates continued usage, and TLS 1.3 clients will continue to receive SHA1-reliant chains for TLS 1.3 connections, and implementors will be incentivised to ignore the spec and trust SHA1 hashes to get it to "just work".

The point you're dodging here is that you can't "require" something and expect that requirement to be followed if you continue disincentivise doing so. Even if most play by the rules, just one deciding that the spec needs to be ignored can cause most others to follow suit. (e.g. the mentality that produced fallback dances)

> unsupported signature algorithm.

I did leave that separate error designation as a "SHOULD" in case of it being dealt with in a library that doesn't provide sufficient feedback to properly deal with. If an endpoint fails in reaction to publicly retrievable information (e.g. server's cert chain), then it should reply with the most relevant error code in order to let the server actually have a clue as to what the issue is and get it fixed.

> contain issuer->subject links that employ SHA-1 signatures.

Essentially, our disagreement is just what to do on the server side of things. I'm saying the server should be required to send non-obsolete certificates and not allowed to assume clients might be able to trust non-root certs directly, as this is not the dominant way certificate authentication is done.

> client certs that include CAcert's MD5 self-signed root.

Why on Earth is anyone still using an MD5 self-signed root? Regardless, "non-root" is acceptable here, if that's sadly still a concern.

> downgrade from unauthenticated TLS to cleartext.  Is that better?

When talking about MD5 still being around, I'm inclined to consider it acceptable collateral damage to avoid presenting a false sense of security, though if the land of half-assed email transport security is still this bad, then this may not be ideal. The correct course of action is of course to not support this connection at all, but that requires more commitment than developers are willing to make to security. That lack of will is _why_ I'm arguing for minimal tolerance of obsolete hashes.

> TLS needs to do *its* job flawlessly, but not overreach.

TLS is not capable of doing its job without sanity checking inputs from related layers. The job of TLS is to provide a secure connection, which it cannot do if it tolerates authentication of clearly obsolete and forgeable certificates when it does not have to. (MD5 being the most brazen example)

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 18:17:17 +0000

On Sun, Oct 11, 2015 at 01:24:36PM -0400, Dave Garrett wrote:

> Every time something is "someone else's problem", it is ensured that the
> problem will not be properly fixed. Security is only as strong as the
> weakest link in the chain, and thus I don't believe a philosophy of complete
> separation of roles is realistic, especially in a world where upgrades
> and fixes are still deployed slowly and badly.

And yet despite your best intentions, defining the semantics of
the certificates *carried* by TLS (but specified elsewhere and
possibly irrelevant to the verifier) is properly outside the purview
of the TLS WG.  We can suggest that in TLS 1.3 SHA-1 signatures
should not be trusted because they are too weak by comparison with
the algorithms used elsewhere in TLS 1.3, we cannot say that peers
must abort handshakes carrying certs with signature algorithms
employing SHA-1, MD5 or even hypothetically CRC-32 certificates on
sight.

> > See above, no crusades.
> 
> Calling the goal of phasing out known-bad features a "crusade" is not
> really helpful. I'm perfectly fine with stating that SHA-1 is reasonable
> to allow in areas where it needs to be for continued transition. It,
> however, should require justification to keep allowance rather than to
> remove.

And yet what you propose is a crusade.  You're no longer looking
at TLS.  You're suggesting we constrain choices outside of TLS,
because we know better, but we don't know better, because TLS has
no knowledge of the application trust model.  So TLS does not get
to dictate which offered certificate chains are to be rejected and
which accepted.  The best we can do is to specify which parameters
are too weak to include in such decisions when and if processing
chain elements that contain such parameters.

> If we consider the certificate authenticated cipher suite scenario within
> TLS to expect this to be the common case, then that gives the false
> impression that admins don't "have" to upgrade because they're "usable".

Nothing of the sort.  We've agreed that TLS 1.3 clients won't trust
SHA-1.  We need to stop there.  We have no choice.  We might like
to be able to be beneficent dictators, but that's not an option.

> Essentially, our disagreement is just what to do on the server side of
> things. I'm saying the server should be required to send non-obsolete
> certificates and not allowed to assume clients might be able to trust
> non-root certs directly, as this is not the dominant way certificate
> authentication is done.

The difference goes further, yes the server must not unilaterally
deny access to a configured SHA-1 chain, but also the client must
not out of hand reject the transmission of such a chain just because
SHA-1 is found.  Rather the client optionally (but typically)
attempts to authenticate the server's certificates, and if that
requires using a SHA-1 cert it might stops there given suitable
requirements in the TLS 1.3 draft, but if none of the presented
SHA-1 certs were needed, then all's well that ends well.  This
subsumes all the use-cases in which some or all of the server's
certificates go unused.

> Why on Earth is anyone still using an MD5 self-signed root? Regardless,
> "non-root" is acceptable here, if that's sadly still a concern.

Ask CAcert.org whose 4096-bit root CA is self-signed with MD5 for
no good reason whatsoever.  And yet there's no problem with that,
the cert is slightly smaller that way, and the self-signature plays
no role in security.

> When talking about MD5 still being around, I'm inclined to consider it
> acceptable collateral damage to avoid presenting a false sense of security,
> though if the land of half-assed email transport security is still this
> bad, then this may not be ideal.

Your "half-assed" is my impressive success, ~80% of outbound email
from Google, that used to go in clear is now encrypted.  What
fraction of HTTP sites have migrated from cleartext?

> The correct course of action is of course
> to not support this connection at all, but that requires more commitment
> than developers are willing to make to security. That lack of will is
> _why_ I'm arguing for minimal tolerance of obsolete hashes.

There is no "lack of will", you're just doggedly ignoring legitimate
use cases.  In all-or-nothing security the majority gets nothing.
I know that opportunistic security is major cognitive dissonance
for security professionals trained to accept no compromises, but
it is fact by making judicious compromises that real progress is
made.

> TLS is not capable of doing its job without sanity checking inputs from
> related layers. The job of TLS is to provide a secure connection, which
> it cannot do if it tolerates authentication of clearly obsolete and
> forgeable certificates when it does not have to. (MD5 being the most brazen
> example)

For opportunistic TLS in SMTP, "secure" means unauthenticated
encryption, for otherwise "secure" means "cleartext" and hope nobody
is looking.  Certificates are just useless baggage to make the
protocol happy.  There is no single all-encompassing security model,
and it is important for this WG to not presume that a single model
is sufficient.

Yes, we're also trying to roll out DANE authentication for email,
but that'll take time, and still protect a fraction of the traffic,
with the majority doing just unauthenticated TLS for quite some
time.

Please start with a sensibly minimal proposal that achieves the
essential goal of deprecating *trust* in SHA-1.  Please do not
overreach by requiring not sending SHA-1 or aborting when receiving
SHA-1.  This is adds nothing of value, just needlessly breaks
legitimate (yes non-primary) TLS use-cases.

Soon enough the trusted CAs will stop issuing certs with SHA-1 in
them, and the problem goes away at that layer.  Libraries that
implement TLS 1.3 while doing PKIX authentication will help out by
not trusting non-root certs with SHA-1, but will accept and process
the peer's chain before deciding whether they can construct a
trusted path to the leaf using any local certificate stores and
whatever the server provided in addition.

You need to step back and accept a reasonable compromise that makes
progress without overreaching.  I'm trying to help, but we must
avoid collateral damage.  What you think is "acceptable collateral
damage" is harmful and unnecessary overreach.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 15:59:43 -0400

> legitimate (yes non-primary) TLS use-cases.

It's getting lost in the long replies, but again, we have already said we both agree with clients not aborting on receiving SHA-1 if trust doesn't rely on it.

I am merely saying that TLS 1.3 servers should consider a certificate chain which does not rely on obsolete hashes as a prerequisite to use certificate authenticated cipher suites. Sorry, but I do not think this is unreasonable. Allowing otherwise is, in my view, an unnecessary risk and should not be the default assumption.

With regard to MD5, I think it's reasonable to allow (not require) implementations to distrust based solely on that. Note that this is _reduced_ from the _current_ draft which has mandatory rejection of all MD5, as I agree that clarifying that ignoring it when not applicable (e.g. bonkers MD5 root) can be valid.

> them, and the problem goes away at that layer.

Organizations can run their own CAs for private use. It's not just about the big public ones. Allowing TLS servers to send SHA-1-reliant chains means considering this to be valid forever.

Someone should not be able to blindly upgrade their system to TLS 1.3 and not even notice that they're still sending SHA-1-reliant chains. One thing we should have all learned over the past couple years is that proper design requires making mistakes less possible, not merely labeling things as potentially unsafe and delegating them appropriately.

> to be able to be beneficent dictators, but that's not an option.

There's always a choice. Perpetuating all design assumptions in a 20 year old protocol ensures perpetuating all chronic flaws that it produces. Each layer cannot blindly trust the other and expect to work in a complex system. It's not that simple anymore.

Case in point: HTTP/2 has a messy set of TLS restrictions because this WG decided against creating a TLS 1.2.1 it could require. Yes, it's not the application layer's role to be picking security settings like that, but the layer it relies on abdicated its role in maintaining a current version with a full set of known-safe configurations. Sure, we may want to "get it right" with TLS 1.3 to get ideal adoption rates, but that doesn't change the fact that HTTP had a problem with its security layer that it needed fixing. Likewise, we cannot safely trust the next layer down in full, because there is no overriding standard to mandate only known-safe configurations, so here we are debating how to best sanity-check cert chains. It's even messier than HTTP, as TLS is the one negotiating the supported algorithms here, so it is not even a fully separate layer.

If the WG consensus agrees with your stance, so be it, but the only safe thing to do is to at least attempt to prohibit servers from considering SHA-1-reliant chains to be safe. (again, roots can do whatever & it's the hash reliance or presumption thereof, not cert itself, that's the issue)

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 11 Oct 2015 17:58:59 -0400

> On Oct 11, 2015, at 3:59 PM, Dave Garrett <[email-masked]> wrote:
> 

Excellent, I'm ready to +1 a PR that says just that and no more for clients.

> I am merely saying that TLS 1.3 servers should consider a certificate chain which does not rely on obsolete hashes as a prerequisite to use certificate authenticated cipher suites. Sorry, but I do…

Well, since anon_DH suites just got removed, and not all servers support them anyway, clients that don't check certificates will still request "certificate authenticated ciphesuites".  So the server has no idea whether its certificates are relevant or not, and must not prevent their transmission if that's all it has.

> With regard to MD5, I think it's reasonable to allow (not require) implementations to distrust based solely on that. Note that this is _reduced_ from the _current_ draft which has mandatory rejecti…

We improve nothing by restricting the content of chain elements that are not used to build trust.  This just promotes the kind of needless failures that I see with opportunistic TLS in Schannel.  Sometimes more is less and less is more.

Pointless restrictions lead to fallback to even worse choices.

> Organizations can run their own CAs for private use. It's not just about the big public ones. Allowing TLS servers to send SHA-1-reliant chains means considering this to be valid forever.

Yes, but they won't be trusted per the core limitation we've already agreed on.  The remaining issue is whether to prohibit the transmission of such chains, and the answer is an unequivocal NO.  Not trusting is plainly sufficient, and strictly better, by not breaking (downgrading) use-cases in which the certificates are otherwise ignored.

> Someone should not be able to blindly upgrade their system to TLS 1.3 and not even notice that they're still sending SHA-1-reliant chains. One thing we should have all learned over the past couple…

They'll notice right away if the client stops trusting them and is doing authentication.  If the client was not doing authentication it will continue to not do authentication (ignore the certs regardless of the signature algorithm).

In your zeal to stamp out SHA-1 you're not going through the case analysis to see that prohibiting less is strictly better.

> There's always a choice. Perpetuating all design assumptions in a 20 year old protocol ensures perpetuating all chronic flaws that it produces. Each layer cannot blindly trust the other and expect…

Yes, we could publish a protocol that shoots itself in the foot and achieves strictly less security than it otherwise would, and would be less interoperable.  I'm not going to sit idly by and let that happen.  Expect objections at every step of the way...

> Case in point: HTTP/2 has a messy set of TLS restrictions because this WG decided against creating a TLS 1.2.1 it could require. Yes, it's not the application layer's role to be picking security se…

We're not reasoning by tenuous analogy.  The proposal you make reduces security, and needs to not move forward.

> If the WG consensus agrees with your stance, so be it, but the only safe thing to do is to at least attempt to prohibit servers from considering SHA-1-reliant chains to be safe. (again, roots can d…

Once clients don't get to advertise SHA-1 in supported algorithms, servers will use SHA-1 only when they have nothing else to offer.  This is enough.  A much shorter PR solves the problem, the rest really is just overreach.

Clients that do the "authentication" in "certificate authenticated ciphersuites" will object to SHA-1 if essential to the chain.  Clients that don't do the "authentication" don't get their connections broken if the server has nothing better.

Breaking opportunistic TLS connections typically leads to cleartext fallback (not progress).  Where's the win in you're proposing beyond a "feel good" posture that've deprecated SHA-1 "harder".  (Sorry to be a bit blunt, but this really is NOT personal, I have a lot of respect for all your hard work in many other PRs, I'm just trying to get this one point across in some manner that will get through).

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 19:13:03 -0400

> Pointless restrictions lead to fallback to even worse choices.

And no restrictions lead to horrible fallback choices. Running under the assumption that some population of implementors is willing to do something stupid to maintain inertia (e.g. insecure version fallback dance), sending SHA1 certs is a risk. Yes, the server doesn't know whether the client can or cannot deal with it safely, but we, from the perspective of the spec, should be assuming bad scenarios when designing things.

> Yes, but they won't be trusted per the core limitation we've already agreed on.  The remaining issue is whether to prohibit the transmission of such chains, and the answer is an unequivocal NO.  No…

A wording change might be helpful here. Instead of no sending of SHA1 certs:
1) SHA1 signatures must not be trusted
2) servers must not send cert chains they do not trust

Yes, I know you'll say that the client can of course trust things the server might not be able to, but the core of what I'm concerned about is servers making an attempt to get clients to accept a chain it knows very well is not trustworthy and thus encourage implementations to accept it anyway.

> They'll notice right away if the client stops trusting them and is doing authentication.

"if"
If servers keep on sending SHA1 indefinitely, we risk clients keep on accepting SHA1 indefinitely, no matter what it says in the spec.

> In your zeal to stamp out SHA-1 you're not going through the case analysis to see that prohibiting less is strictly better.

Clearly we are both analyzing the scenarios here, but coming to different conclusions based on different assumptions and priorities. Same goal; different approach.

> Once clients don't get to advertise SHA-1 in supported algorithms, servers will use SHA-1 only when they have nothing else to offer.

If servers still commonly send SHA-1, then clients will never stop offering support for it.

> Breaking opportunistic TLS connections typically leads to cleartext fallback (not progress).

Prohibiting TLS 1.3 implementations from using SHA1 certs does not break OE. TLS 1.2 does not cease to exist, and an server implementation can happily run in a TLS 1.2 only mode until both the TLS implementation and cert chain are upgraded.

> Where's the win in you're proposing beyond a "feel good" posture that've deprecated SHA-1 "harder".

My goal is to have fewer systems using SHA1 within a reasonable timeframe. The current TLS 1.3 draft completely delegates that issue away in a manner which does not put any onus on servers to upgrade, instead relying entirely on unspecified outside forces to deal with the issue (e.g. CA/Browser Forum; clients hopefully saying no, eventually).

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 12 Oct 2015 00:00:45 +0000

> 1) SHA1 signatures must not be trusted

Excellent.

> 2) servers must not send cert chains they do not trust

Pointless overreach that breaks things.

> Yes, I know you'll say that the client can of course trust things the
> server might not be able to, but the core of what I'm concerned about is
> servers making an attempt to get clients to accept a chain it knows very
> well is not trustworthy and thus encourage implementations to accept it
> anyway.

You're still ignoring the fact that in many environments the client
(correctly) does not validate the chain via trust-anchors of any
kind, so signatures of certificates by some "issuer" are of interest
to the client.  There is no reason for the server to avoid sending
the chain even if some "signer" in the chain happened to use SHA-1.

At a minimum a leaf cert signed with SHA-1 may still be valid by
means other than trust of its signature.

> If servers keep on sending SHA1 indefinitely, we risk clients keep on accepting SHA1 indefinitely, no matter what it says in the spec.

Some implementations might even ignore any misguided text telling
them to not send the chain. :-)  We can't design for non-conformant
implementations.  You sure want that cherry on top.  However right
it might feel, it would still be counterproductive.

> If servers still commonly send SHA-1, then clients will never stop offering support for it.

No, that conclusion is unwarranted.  TLS 1.3 clients will not trust
SHA-1.  All the key implementors are reading this interminable
thread.  They understand the issues.  If we get consensus for at
least the minimal version (no trust in SHA-1) we're done.  There's
no reason for pessimism, we're not trying to deprecated deployed
functionality, there is no TLS 1.3 deployed base.  We can start
"clean" and keep it that way.

> Prohibiting TLS 1.3 implementations from using SHA1 certs does not break
> OE.  

It does when the SHA-1 leaf certificate is pinned, and/or the server
has nothing else to send, and its clients rightly don't care.

> My goal is to have fewer systems using SHA1 within a reasonable timeframe.

That happens automatically in the minimal version of the PR.

    1.  Recall that the SHA-1 certs are not trusted by TLS 1.3
        clients, so the vast majority of servers will need SHA2-256 certs.

    2.  Recall that public CAs are phasing out SHA-1 certs sooner
	than a non-negligible number of systems is likely to deploy
	TLS 1.3

> The current TLS 1.3 draft completely delegates that issue away in a manner
> which does not put any onus on servers to upgrade, instead relying entirely
> on unspecified outside forces to deal with the issue (e.g. CA/Browser
> Forum; clients hopefully saying no, eventually).

We've agreed to require clients to not trust SHA-1 signatures.  That's
quite enough, and is a smaller, simpler change.

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 22:41:44 -0400

On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote:
> There's no reason for pessimism

Sorry, I have to laugh a bit here. :p

> we're not trying to deprecated deployed
> functionality, there is no TLS 1.3 deployed base.

Due to the fact that the vast majority of TLS implementations that will be used are going to be existing ones, upgraded to support TLS 1.3, yes we are deprecating deployed functionality for that implementation as well as their users.

> has nothing else to send, and its clients rightly don't care.

In the second case, a correct course of action for the server would be to send an incomplete or outright empty certificate_list fallback, in which case the clients that don't care will be fine with it. Pinning a SHA1 end-entiy (leaf) cert rather than an intermediate just seems like a bad idea that you can't expect to work forever. In cases where the server can't handle lack of SHA1, then my response is to fix that before upgrading TLS.

> That happens automatically in the minimal version of the PR.

We're both trying to predict possible futures with different thought processes. I'm concerned that the simpler course is too slow, _not_ because we need to rush to get rid of SHA1 certs ASAP, but because going slower requires keeping SHA-1 around in implementations in the interim. Even requiring settings and code for an algorithm at all poses an attack surface by itself (we had attacks on supposedly disabled features over the past year). Every known vulnerable feature is one which we have to be wary of getting re-enabled or left on accidentally. I consider this risk to be high enough to not rely on delegation to another layer; you think that delegation cannot be changed without excessive interop risk.

I'll post a follow-up question to the WG (with a changed title, as our discussion here got long) with the options phrased as a question with 3 main choices (including the option of doing nothing new). If there's no support for a full drop in SHA-1 support under the new version, then there won't be a point in pushing for it further, unless there's yet another SHA-1 revelation in the near future.

Dave

---

From: Dave Garrett <[email-masked]>
Date: Sun, 11 Oct 2015 22:43:03 -0400

I'd like to get a sense of what the WG is willing to consider with regard to SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3 options:

Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable option in TLS 1.3 if nothing better is installed.
Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1 signatures (but may trust full certificates, namely roots).
Option 2: Distrust (option 1) and also prohibit endpoints from sending chains that rely on SHA-1 signatures to their peers when negotiating TLS 1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your certificates; self-signed roots still exempt)

No change is proposed with regard to dealing with SHA-1 under TLS 1.2 beyond the current state. TLS 1.3 already prohibits using SHA-1 in CertificateVerify. This discussion is only for TLS 1.3+ non-root certificates. The TLS 1.3 release is not yet near (assume we're talking about 2016, when others are phasing out SHA-1 more strictly as well).

I am in favor of #2, as I don't think the risk of keeping it in the spec is worth continued support (SHA-1 is on its way out, and TLS 1.3 shouldn't perpetuate its use). Viktor Dukhovni is in favor of #1, and considers prohibiting servers from sending SHA-1 certs to be sufficiently out-of-scope and not worth the interop risk (opportunistic encryption and direct trust of certificates, of note). Two opinions does not a working group make, so more input is clearly needed to move forward in any way here.

This is only a preliminary call for opinions, and certainly not a policy deciding vote.

The new reason to consider this:
https://sites.google.com/site/itstheshappening/
Current draft language:
https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-60
Start of the parent thread:
https://www.ietf.org/mail-archive/web/tls/current/msg17956.html

Dave

---

From: "Ryan Sleevi" <[email-masked]>
Date: Sun, 11 Oct 2015 20:12:40 -0700

On Sun, October 11, 2015 7:43 pm, Dave Garrett wrote:
>  I'd like to get a sense of what the WG is willing to consider with regard
>  to SHA-1, rather than only Viktor and myself discussing this. Basically, I
>  see 3 options:
>
>  Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully
>  viable option in TLS 1.3 if nothing better is installed.
>  Option 1: Explicitly state that TLS 1.3+ clients must not trust SHA-1
>  signatures (but may trust full certificates, namely roots).
>  Option 2: Distrust (option 1) and also prohibit endpoints from sending
>  chains that rely on SHA-1 signatures to their peers when negotiating TLS
>  1.3. (aka, don't upgrade to TLS 1.3 until you've upgraded your
>  certificates; self-signed roots still exempt)

My personal preference, speaking on behalf of myself and neither that of
my employer or colleagues (we are all individuals here, right? ;D), would
be Option 0.

If that's all you care to know, stop here - the rest is pontificating and
poorly articulating why :)

Background:
It's no secret I hate SHA-1. I'm accused by a number of Chrome users as
being too aggressive in the deprecation of SHA-1. I'm unquestionably
accused by CAs of being too harsh on SHA-1 - my opposition towards any
extension of SHA-1 signatures by CAs complying with the CA/Browser Forum
Baseline Requirements is unquestionable and well known.

Why would I support "do nothing"-ism, which is effectively what Option 0 is?

Two reasons:
- I agree with Viktor that TLS is a protocol for which many credential
types can be delivered, and while I have no desire nor intent to support a
number of them within Chrome (... I'm looking at you, DANE), I don't deny
their utility or viability in some circumstances and environments beyond
that of web browsers. It feels inconsistent to apply this to one specific
type of credentials, with a particular policy. This is an ideological
argument for specification purity, fundamentally, so I fully anticipate
disagreement, as is expected with such arguments.

- Simply one of complexity. The modern TLS stack, as used in Web browsers
(thus revealing my bias, as if we didn't know it already) is already hairy
and complex. HTTP/2 imposes a (much needed) profile on ciphersuite
negotiations. Browsers themselves key UI off a variety of factors
contributing to the connection, both direct (e.g. ciphersuite) and
indirect (e.g. mixed content). If we accept that browsers are only
concerned with the Web PKI (I know some wish it were otherwise), then the
WebPKI is messy, and whether or not a certificate is signed by SHA-1 is...
complex and complicated and invokes path building and cross certificates
and many of the things outside the remit of TLS.

This certificate path building and discovery depends on a variety of
factors and external resources (and here's where Martin Rex would chime in
about how awful such a state is, but let's accept it as the state of the
world today and not argue about necessity or not), and implementing such a
policy necessarily interleaves that into the connection management.

The 'gross' state of my world today, which will no doubt shock and offend,
is that in many cases and ways, the verification of the server identity is
deferred until after the overall connection has been established, before
any data is transferred over it, and before any keys, session parameters,
or overall state is persisted for reuse. The alternative to this is to do
something akin to Firefox, which does verification semi-synchronously
during handshaking, but which doesn't fetch such external resources (and
thus has a much harder time interacting with nominally 'secure' sites),
and which if it did, would trigger the various 'retry' logic to deal with
servers that time out if the handshakes fail to happen in a 'reasonable'
time.

Look, I think the deprecation of SHA-1 is a noble goal - hopefully my
bonafides are established such that few would want it more - but my
concern is that it would add significant implementation complexity to my
world, and fundamentally offer no benefit for my existing and documented
plans.

Were I (and my colleagues) to ignore such a MUST, for entirely pragmatic
and yet equally secure reasons, we'd end up cheesing off folks like Dave
and those who treat MUSTs as inviolate (reasonably and rightfully so), and
would be seen as tacitly encouraging others to ignore such MUSTs as well.
I'd like to avoid that world.

I think the reasons for such a proposal are laudable, but the pragmatic
application and interpretation of such a requirement would be
confoundingly obnoxious, and to no obvious benefit, since I (and my
counterparts at various other browser organizations) am well on my way to
killing SHA-1 within the commercial space.

So the only party left to all this is the Enterprise folk, those who will
always override a MUST with an application profile, or who will always
deal with legacy in such a way that, practically speaking, such a MUST is
toothless.

Such a requirement doesn't help my efforts towards the death of SHA-1 and
evangelizing the need for such a death, and would only distract myself and
my colleagues from implementing TLS 1.3 as quickly as reasonable and
possible. Maybe it will help in some niche ecosystems that still hold to
SHA-1 as the bastion of security, but frankly, may the deity/deities they
worship have mercy on their misguided souls.

---

From: Sean Turner <[email-masked]>
Date: Mon, 12 Oct 2015 00:43:09 -0400

I’m going to close this thread.  We discussed SHA-1 support in TLS on the list and at the interim the chairs made the consensus call that PR#231 reflects the WG’s consensus.

Note that Stephen started a thread on the saag list about further work to remove SHA-1 from protocols [1]; maybe the references both Dave and Stephen cite will accelerate the demise of SHA-1 issued certs.

spt

[1] http://mailarchive.ietf.org/arch/msg/saag/1iiiMLJmrtEMSmghoYO6lC_xje4

---

From: Hubert Kario <[email-masked]>
Date: Mon, 12 Oct 2015 14:49:16 +0200

On Sunday 11 October 2015 19:13:03 Dave Garrett wrote:
> And no restrictions lead to horrible fallback choices. Running under
> the assumption that some population of implementors is willing to do
> something stupid to maintain inertia (e.g. insecure version fallback
> dance), sending SHA1 certs is a risk. Yes, the server doesn't know
> whether the client can or cannot deal with it safely, but we, from
> the perspective of the spec, should be assuming bad scenarios when
> designing things.

so what we need is:
 1. servers SHOULD NOT send certificates with SHA-1 signatures, except 
    as a last resort (maybe even add a recommendation that 
    implementers should warn user when such certificates are configured)
 2. clients MUST NOT trust certificates which derive their authenticity
    though SHA-1 (or weaker) signatures

but saying that the server MUST NOT send SHA-1 (or other certs) is, as 
Victor said, an overreach
-- 
Regards,
Hubert Kario
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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 12 Oct 2015 13:44:51 +0000

In summary: 
+1 to Viktor’s argument.
-1 to Dave’s.
--
Regards,
Uri Blumenthal

On 10/11/15, 22:41, "TLS on behalf of Dave Garrett" <[email-masked]
on behalf of [email-masked]> wrote:

>Due to the fact that the vast majority of TLS implementations that will
>be used are going to be existing ones, upgraded to support TLS 1.3, yes
>we are deprecating deployed functionality for that implementation as well
>as their users.
>
>In the second case, a correct course of action for the server would be to
>send an incomplete or outright empty certificate_list fallback, in which
>case the clients that don't care will be fine with it. Pinning a SHA1
>end-entiy (leaf) cert rather than an intermediate just seems like a bad
>idea that you can't expect to work forever. In cases where the server
>can't handle lack of SHA1, then my response is to fix that before
>upgrading TLS.
>
>We're both trying to predict possible futures with different thought
>processes. I'm concerned that the simpler course is too slow, _not_
>because we need to rush to get rid of SHA1 certs ASAP, but because going
>slower requires keeping SHA-1 around in implementations in the interim.
>Even requiring settings and code for an algorithm at all poses an attack
>surface by itself (we had attacks on supposedly disabled features over
>the past year). Every known vulnerable feature is one which we have to be
>wary of getting re-enabled or left on accidentally. I consider this risk
>to be high enough to not rely on delegation to another layer; you think
>that delegation cannot be changed without excessive interop risk.
>
>I'll post a follow-up question to the WG (with a changed title, as our
>discussion here got long) with the options phrased as a question with 3
>main choices (including the option of doing nothing new). If there's no
>support for a full drop in SHA-1 support under the new version, then
>there won't be a point in pushing for it further, unless there's yet
>another SHA-1 revelation in the near future.
>
>
>Dave
>