Subject: [TLS] Alerts

From: Matt Caswell <[email-masked]>
Date: Wed, 10 May 2017 16:21:23 +0100

Draft-20 currently contains this text in the section "Server
Certificate Selection":

'If the client cannot construct an acceptable chain using the provided
certificates and decides to abort the handshake, then it MUST abort
the handshake with an"unsupported_certificate" alert."'

However, section 6 lists a number of other generic certificate related alerts:
certificate_revoked
certificate_expired
certificate_unknown
unknown_ca

While section 6 provides descriptions of these they are not mentioned
elsewhere in the spec, so there is no guidance as to when they might
be used.

So, given the text in the "Server Certificate Selection" section,
should a client always send "unsupported_certificate" for all
failures? Or should one of the other alerts be used instead if it
seems more appropriate? E.g. If a client attempts to "construct an
acceptable chain", but finds an expired certificate - should it
respond with "unsupported_certificate" or "certificate_expired"?

There seems to be some inconsistency between server certificate
selection and client certificate selection, i.e. in the former it is
mandated that a specific alert be sent, but in the latter there is no
such requirement.

Additionally, there are a number of other alerts mentioned in section
6 (not just certificate related ones), that are never mentioned
anywhere else in the spec. Do we really need all of these alerts? If
they are needed, shouldn't they be explicitly mentioned elsewhere in
the spec in the locations where they are relevant (associated with
some MUST/SHOULD/MAY requirement)? As things stand the interpretation
of when they should be sent seems quite loose.

Matt

---

From: Martin Thomson <[email-masked]>
Date: Thu, 11 May 2017 06:51:53 +1000

On 11 May 2017 at 01:21, Matt Caswell <[email-masked]> wrote:
> Do we really need all of these alerts?

NSS uses these, but in ways that I don't really understand.  I think
that this is part of the general issue that TLS does and doesn't
really include requirements about how to handle the certificate chain.

---

From: Matt Caswell <[email-masked]>
Date: Thu, 11 May 2017 09:21:31 +0100

> really include requirements about how to handle the certificate chain.

OpenSSL is quite inconsistent in its use of alerts. That's how this
issue came up for me - I was reviewing what the spec said about alerts
and comparing it to the OpenSSL implementation (checking we failed
everywhere we are supposed to fail, and with the correct alert).
OpenSSL is currently using the more specific alerts for certificate
failures, although this is in contradiction to what it says in the
"Server Certificate Selection" section.

If the view is that the more specific alerts are helpful, then I'd
suggest amending the wording in the "Server Certificate Selection"
section to remove the bit about the "unsupported_certificate" alert
and (possibly) replace with a reference to the set of alerts that
might be sent instead.

Alternatively, if the more specific alerts are not helpful, then
perhaps we should prune down the list in section 6 to a much smaller
list.

Matt

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 11 May 2017 16:06:37 -0400

> On May 11, 2017, at 4:21 AM, Matt Caswell <[email-masked]> wrote:
> 

It can be quite difficult for users to understand why a remote peer
aborted the TLS handshake.  More specific alerts are quite helpful.
Distinguishing between expiration and insufficiently strong keys or
digests, etc., makes troubleshoots easier and does not compromise
sensitive cryptographic material.

-- 
	Viktor.

---

From: Matt Caswell <[email-masked]>
Date: Fri, 12 May 2017 14:46:09 +0100

> sensitive cryptographic material.

That seems reasonable to me.

https://github.com/tlswg/tls13-spec/pull/1013

Matt