Subject: [TLS] Consensus on PR 169 - relax certificate list requirements

From: Joseph Salowey <[email-masked]>
Date: Wed, 26 Aug 2015 14:11:01 -0700

It looks like we have good consensus on PR 169 to relax certificate list
ordering requirements.  I had one question on the revised text.  I'm
unclear on the final clause in this section:

"Because certificate validation requires that trust anchors be distributed
independently, a self-signed certificate that specifies a trust anchor MAY
be omitted from the chain, provided that supported peers are known to
possess any omitted certificates they may require."

I just want to make sure there isn't the intention of omitting certificates
that are not seif-signed.

Thanks,

Joe

---

From: Dave Garrett <[email-masked]>
Date: Wed, 26 Aug 2015 17:42:00 -0400

> that are not seif-signed.

Well, technically anything can be omitted; it just won't validate. :p

I'm not opposed to tweaking the wording here, but I don't really see it as a problem. If someone does, though, that's reason enough for me to agree to changing it.

Simplest change is:
"any omitted certificates they may require"  ->  "it"
\/
"Because certificate validation requires that trust anchors be distributed
independently, a self-signed certificate that specifies a trust anchor MAY
be omitted from the chain, provided that supported peers are known to
possess it."

Dave

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Aug 2015 14:43:21 -0700

> possess any omitted certificates they may require."

I always thought that the primary reason for omitting a certificate
was that you had a good reason to expect that clients had the
certificate already.  Whether the certificate is self-signed seems
like a poor proxy for that.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 26 Aug 2015 21:50:23 +0000

> that are not seif-signed.

There is no such intention, the new text in question expands on
existing text in previous versions of TLS that specifically blesses
omission of self-signed issuers.  Such omission is no longer
universally applicable, since with DANE-TA(2) for example, even
self-signed issuers MUST be included in the server chain.

    https://tools.ietf.org/html/draft-ietf-dane-ops-16#section-5.2.2

So the intent here is to hedge  the circumstances under which chain
elements are ommitted.  This is not an attempt to bless further
chain optimization.  What's new here is the "provided that ...".

-- 
	Viktor.

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 26 Aug 2015 22:25:07 -0700

Thanks Viktor,  I missed this part of the discussion.  The text looks fine
to me as is.

Joe

On Wed, Aug 26, 2015 at 2:50 PM, Viktor Dukhovni <[email-masked]>
wrote:

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 27 Aug 2015 13:22:33 -0400

To me it seems that both of these wordings could be interpreted by someone
that if you do not have a trust anchor and you get it in the TLS handshake,
you can use it and trust it.

That sounds dangerous.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Dave Garrett
Sent: Wednesday, August 26, 2015 5:42 PM
To: [email-masked]
Subject: Re: [TLS] Consensus on PR 169 - relax certificate list requirements

On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote:
> It looks like we have good consensus on PR 169 to relax certificate 
> list ordering requirements.  I had one question on the revised text.  
> I'm unclear on the final clause in this section:
> 
> "Because certificate validation requires that trust anchors be 
> distributed independently, a self-signed certificate that specifies a 
> trust anchor MAY be omitted from the chain, provided that supported 
> peers are known to possess any omitted certificates they may require."
> 
> I just want to make sure there isn't the intention of omitting 
> certificates that are not seif-signed.

I'm not opposed to tweaking the wording here, but I don't really see it as a
problem. If someone does, though, that's reason enough for me to agree to
changing it.

Simplest change is:

Dave

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 27 Aug 2015 17:29:47 +0000

> you can use it and trust it.

Beyond a general "there's no such thing as fool-proof", I don't
see how such an interpretation might be arrived at.

Trust-anchors are both frequently sent and frequently not sent in
the TLS handshake.  The new text just says that it may be acceptable
to omit them, but sometimes clients need the trust-anchor certificate
to be sent, because they verify it by fingerprint or similar, and
don't have a (complete) local copy.

The text is fine.

-- 
	Viktor.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 31 Aug 2015 14:02:03 +0200

> Well, technically anything can be omitted; it just won't validate. :p

Firefox completes chains with intermediate certificates it has seen in
other certificate chains.  This is an endless source of headaches if you
use headless clients which do not perform this caching.

In this light, MUST NOT automatically complete incomplete chains, except
with a trusted root certificate (self-signed or not) might an attractive
option.  Except that Mozilla could claim its self-learning trust store
is just magically growing root certificates in the sense of such a
requirement (although such certificates are necessarily intermediate,
otherwise it would not be safe to mark them as trusted automatically).

-- 
Florian Weimer / Red Hat Product Security

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Aug 2015 08:54:16 -0700

On 31 August 2015 at 05:02, Florian Weimer <[email-masked]> wrote:
> MUST NOT automatically complete incomplete chains

Um, no.  I realize that this is a feature that is hard for others to
replicate, but being able to reach sites is important to people.  All
browsers do this, and I don't see any reason to stop.

---

From: Florian Weimer <[email-masked]>
Date: Mon, 31 Aug 2015 17:56:26 +0200

> browsers do this, and I don't see any reason to stop.

The reason to stop is that people only test with long-running, well-used
browser profiles, and it is difficult to explain to them that things
don't work if you just installed a fresh system.  I lost countless hours
to that.  As in other cases, browsers papering over site configuration
errors causes ecosystem damage.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Aug 2015 08:59:06 -0700

> errors causes ecosystem damage.

I tell you what, we'll stop:
a) after all the other browsers stop, and
b) when the number of sites that become unreachable as a result is low
enough (I think that 1/1000 connections might be high)

I know that it sucks, but it's hard to turn off something like that
when it has a large compatibility risk and no security upside.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 31 Aug 2015 19:03:03 +0300

> On Aug 31, 2015, at 6:56 PM, Florian Weimer <[email-masked]> wrote:
> 

I feel the pain (I know some administrators who have made this mistake), but it’s always best to test with something like “openssl s_client”.

Yoav