Subject: [TLS] Update spec to match current practices for certificate chain order

From: Dave Garrett <[email-masked]>
Date: Wed, 6 May 2015 23:13:05 -0400

https://tools.ietf.org/html/rfc5246#section-7.4.2
----------------------------------------------------------------------
   certificate_list
      This is a sequence (chain) of certificates.  The sender's
      certificate MUST come first in the list.  Each following
      certificate MUST directly certify the one preceding it.  Because
      certificate validation requires that root keys be distributed
      independently, the self-signed certificate that specifies the root
      certificate authority MAY be omitted from the chain, under the
      assumption that the remote end must already possess it in order to
      validate it in any case.
----------------------------------------------------------------------

It seems that in practice, nobody cares about that second "MUST".

https://bugzilla.mozilla.org/show_bug.cgi?id=619445#c1

I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST")

I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 May 2015 08:49:21 +0300

Hi, Dave

> On May 7, 2015, at 6:13 AM, Dave Garrett <[email-masked]> wrote:
> 
> It seems that in practice, nobody cares about that second "MUST”.

It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing code anyway.

> I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem to do. (no change proposed for the first "MUST”)

People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

> I think there was also discussion on this list at some point suggesting changing that "MAY" for omitting the root CA cert to a "SHOULD" or a "MUST". (I think the argument for the latter was to redu…

SHOULD is OK, MUST would imply perfect knowledge of how the other side is configured. The root of trust may or may not be the self-signed certificate. But it’s probably always fine to omit the self-signed certificate.

> Any reason this would be problematic? It'd be a simple change to add for the TLS 1.3 spec that would align things better with real-world usage.

None that I can think of

Yoav

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 7 May 2015 05:50:18 +0000

Dave Garrett <[email-masked]> writes:

>I'd like to propose simply changing that second "MUST" to a "SHOULD" or
>possibly even a "RECOMMENDED", thus allowing for clients to accept cert
>chains in different orderings as they already seem to do. (no change proposed
>for the first "MUST")

I suspect the first MUST can go as well, particularly if you're using code
that handles cert chains in other formats like CMS/PKCS #7, where the "chain"
can contain any old rubbish and the chain-assembly code has to build the path.
For example my code looks for a cert containing the site name 
("www.whatever.com") and then builds a chain up via the parent links until it
can't find any more useful certs.  That just works no matter what the other
side sends.

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 May 2015 06:59:24 +0000

On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote:

> > I think there was also discussion on this list at some point suggesting
> > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a
> > "MUST". (I think the argument for the latter was to reduce wasted bandwidth)

Sorry, this is incompatible with use of DANE TLSA records when the
ceritificate usage is DANE-TA(2).  See:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.2
    https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2

The first of these is currently in IETF LC, the second in DANE WG LC.

> SHOULD is OK, MUST would imply perfect knowledge of how the other side is
> configured.

As you note, there is more than one way to verify certificates,
and the server cannot know exactly which certificates are needed
by the client.  A SHOULD or MUST would be counter-productive.

> The root of trust may or may not be the self-signed certificate.
> But it?s probably always fine to omit the self-signed certificate.

No, not always.

> > Any reason this would be problematic? It'd be a simple change to add
> > for the TLS 1.3 spec that would align things better with real-world usage.
> 
> None that I can think of

You won't be able to say that next time. :-)

-- 
	Viktor.

---

From: Dave Garrett <[email-masked]>
Date: Thu, 7 May 2015 03:00:04 -0400

> It’s not that nobody cares about that second MUST. It’s just that we’ve learned the hard way that a lot of servers get it wrong, so we anyway had to run the whole chain-sorting/chain-completing cod…

By "nobody cares" I mean that clients seem to be fine handling this now, even if they'd rather not have had to. I don't see vendors evangelizing the proper ordering of certs as a high priority.

> People get it wrong, so let’s make it easy for them by relaxing the requirement?  Bleh. Might save some people from learning the hard way that others get it wrong.

Well, we don't get anything from telling people to panic and abort the connection if it's wrong. Handling the possibility of out-of-order certs is already a thing that has to be done in practice, so stating that up front would improve real-world interop for any clients that might've done otherwise.

In any case, there's not much point in having a "MUST" in the spec that doesn't really help and won't be enforced.

>  But the thing with SHOULDs is that we usually want an explanation of when it is OK to not follow the SHOULD. I can’t think of any text for that.

With Mozilla's phase out of 1024-bit roots, some sites followed recommendations to have two intermediates as a transitional measure. This may be useful for future transitions as well. (not clear on the details here; please correct me if I'm wrong)

> can't find any more useful certs.  That just works no matter what the other

We might just want to SHOULD-ify the whole thing, then.

Here's a stab at a rewrite with SHOULDs and generalized language:
----------------------------------------------------------------------
  certificate_list
     This is a list of certificates needed for authentication.
     The sender's certificate SHOULD come first in the list, followed
     by additional certificates ordered by increasing authority.
     (e.g. sender, intermediate(s), certificate authority)
     Root certificate authority certificates SHOULD NOT be provided
     in this list, as validation generally requires the root keys be
     distributed independently.
----------------------------------------------------------------------

That may need some tweaking, but I think it clearly outlines the expectations and reasoning.

How does that sound?

Dave

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 May 2015 15:52:14 +0200 (CEST)

> https://tools.ietf.org/html/rfc5246#section-7.4.2

That isn't quite accurate.

Up to 2013 our SSL implementation has been hard failing TLS handshakes
with TLS peers that are sending garbled or incomplete chains.

In 2013, I added a _simple_ reordering before certficate path validation.
Missing certificates or alien certificates are still going to result
in a fatal handshake failure.
 
The one thing that I fail to understand: why did SSL implementations
add sorting into the recipient side processing of the TLS Certificate
handshake message, but *NOT* at the same time fix their sender-side
processing of that handshake message to *NOT* send bogus certificat_lists
in the first place.  One of the most notorious offenders is OpenSSL.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 7 May 2015 15:57:58 +0200 (CEST)

> can contain any old rubbish and the chain-assembly code has to build the path.

That would be a terrible idea.  I believe that there is a non-marginal
number of TLS implementations that requires the end-entity certificate
to come first in the list, not just ours. 

> can't find any more useful certs.  That just works no matter what the other

Adding workarounds for clearly bogus behaviour is a very bad strategy,
because it makes the situation worse for everyone in the long run.

-Martin

---

From: Geoffrey Keating <[email-masked]>
Date: 07 May 2015 15:49:55 -0700

> > I'd like to propose simply changing that second "MUST" to a "SHOULD" or possibly even a "RECOMMENDED", thus allowing for clients to accept cert chains in different orderings as they already seem…

I'd like to see wording as follows:

     This is a sequence of certificates.  The sender's certificate
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in the first certificate.
     The sender SHOULD order these remaining certificates so that each
     certificate is used to establish trust in a certificate earlier
     in the order, and so that its preferred certificates are listed
     first.

This answers the problem of multiple certificate paths, and doesn't
prevent re-ordering by the client, and also allows the server to guide
the client to the chain it prefers, which is important in some
circumstances.  For example, one chain might support EV, and another
might be necessary for older clients, but both might be valid in some
clients; the server would want to guide the client to the EV chain if
it will work.

Another alternative would be to say

     This is a sequence of certificates.  The sender's certificates
     MUST come first in the list.  The remaining certificates MAY be
     used by the client to establish trust in one of the sender's
     certificates.  The sender SHOULD order these remaining
     certificates so that each certificate is used to establish trust
     in a certificate earlier in the order, and so that its preferred
     certificates are listed first.

This explicitly allows the sender to send multiple certificates for
itself, which would simplify a bunch of problems; SNI is no longer
necessary (but still desirable), and it's no longer necessary to
negotiate the certificate signing algorithms.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 7 May 2015 21:51:53 -0700

>  clients; the server would want to guide the client to the EV chain if

The problem I have with that proposal is it conflicts with RFC 4158 and
conflicts with client practice [at least, those most likely to be
encountered at the web at large, in the context of HTTPS]

That is, yes, it's true, you can totally send based on the server's
preference, but there is zero obligation for the client to respect that
preference - and indeed, no clients that support path discovery (rather
than just path building) that I've observed actually would respect such an
order. That is, they do RFC 4158 style optimizations, ranging from caching
the certificate validation path to using application-determined
preferences (ranging from issuance date, key strength, etc)

This sort of goes back to it being a change to the path building APIs to
accommodate such language - the same reason that the current MUST is
ignored.

(Yes, I'm aware that libraries that simply perform path _verification_ -
notably, OS X's & iOS's Security.framework and OpenSSL & derivatives -
would implicitly respect such preferences. But they also fail fairly
miserably at dealing with the Web PKI, as evidenced by OS X's repeated
issues whenever there is a CA cross-signing or rollover, which has been
quite common the past few years, so I don't particularly consider their
behaviours emblematic of good behaviours)

Admittedly, it's harmless language from a client implementation side - but
I fear that by describing it as such, it sets up an indirect expectation
for servers and readers that clients SHOULD respect such ordering, when
there is no such requirement and it'd be even more work to do than the
current MUST.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 8 May 2015 13:23:41 +0100

> https://tools.ietf.org/html/rfc5246#section-7.4.2

No thanks. Let's not encourage bad practices. For a start, if you
relax the requirement you allow for ambiguous chains.

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

---

From: [email-masked] (Martin Rex)
Date: Fri, 8 May 2015 17:51:56 +0200 (CEST)

The _existing_ description of the Contents of the TLS Certificate
handshake message is among the few things that I really like in the TLS
specification, and I believe that none of the proposed changes improves
it, but many break it, or break it badly.

> negotiate the certificate signing algorithms.

Huh???

This doesn't compute.  There is just one digitally-signed object
(or static RSA key exchange in TLS up to v1.2), so there is no
"choice" among multiple server certificates.

And every sensibly managed public CA ought to refuse signing the
same public key for different names/identities/attributes (i.e.
issuing different certs with the same public key).

-Martin

---

From: Geoff Keating <[email-masked]>
Date: Fri, 8 May 2015 13:18:05 -0700

> On 8 May 2015, at 8:51 am, Martin Rex <[email-masked]> wrote:

> "choice" among multiple server certificates.

There can be multiple certificates with the same public key, but different subject identification.