Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 May 2015 18:20:52 +0000

> If you'd like to explain how formally documenting existing behavior (that we are not otherwise proposing be changed) will somehow reduce interoperability further, then please do so on the mailing list.

Okay, I'll try.

We already have non-compliant behavior, even though the spec is pretty clear and some implementations rely on compliance with that spec. And nobody has said that it's a BAD requirement, just that it's not universally implemented.

Sliding back from the current requirement seems like it will only add to the wiggle room and allow even more aberrant behavior.  The collapse of Western civilization, dogs and cats sleeping together, etc.  Okay, perhaps I exaggerate.

Rather than giving up, we should be spending any effort to get compliance.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 11 May 2015 11:41:56 -0700

On Mon, May 11, 2015 11:20 am, Salz, Rich wrote:
> > If you'd like to explain how formally documenting existing behavior
> > (that we are not otherwise proposing be changed) will somehow reduce
> > interoperability further, then please do so on the mailing list.
>
>  Okay, I'll try.
>
>  We already have non-compliant behavior, even though the spec is pretty
>  clear and some implementations rely on compliance with that spec. And
>  nobody has said that it's a BAD requirement, just that it's not
>  universally implemented.

That's not true. I've explicitly stated it's a BAD requirement, and tried
to give concrete examples.

I'll be explicit:

1) I think clients, such as Martin's, that implement normative checking of
ordering and are used for the Internet at large (e.g. between servers and
clients that are not controlled by a single entity) are bad for Internet
security.
2) I think clients, such as Martin's and Geoff's, that do not implement
RFC 4158 path discovery are bad for Internet security.
3) I think language that encourages or requires clients to normatively
enforce such ordering are bad for Internet security.

So to be clear, I disagree with my colleague, Ben Laurie, rather
substantially here.

The context is that:
1) I'm involved in maintaining one of the largest client web browsers' PKI
stack. Thus, I deal with brokenness on a daily basis.
2) I'm involved in dealing with the PKI stacks of a variety of platforms,
some open-source, some closed-source, and with a variety of versions.
3) I'm involved in the CA/Browser Forum and have spent the past several
years trying to work in deprecation of insecure cryptography (in the case
of certificates, SHA-1, RSA signatures <= 1024-bits, and in general, RSA
signatures vs ECC)

I say all this to say "I've seen things", and when it comes to gross
hacks, few people are as more affected and have more visibility to them
than those doing things similar to me.

All of that to say I think the current language encourages bad practice.

In my original email, I tried to establish why:
1) Clients have disparate trust-stores. Absent the X.500 directory, this
is a fact of life. The set of trust anchors recognized by Microsoft will
and is different than those recognized by Mozilla, for a variety of
legitimate reasons that will not change, no matter what the IETF does.
2) As such, there is no single trusted path. RFC 4158 spells this out in
abundant detail, and the figures contained should be "required skimming"
for any of this discussion.
3) Implementing path discovery is hard. RFC 4158 spells out why. It's also
necessary, as the first two points here spell out. Clients that don't
support RFC 4158 "break" if a trusted path cannot be found.

In order to handle deprecations of SHA-1, for example, certificate paths
need to be replaced with their SHA-256 equivalent. To handle the
deprecation of RSA-1024 bit, alternative paths must be supplied. To handle
the deprecation of RSA in favour of ECC, alternative paths must be
supplied.

If you fail to supply those, clients break.
When clients break, servers have to choose between breaking clients and
doing the right thing or keeping clients working.
For obvious and understandable business reasons, "keeping clients working"
is always going to be the preferable case.
"Keeping clients working" is equivalent to "holding security back"

So servers do the sensible thing. They try to find a way to keep clients
working WHILE doing the right thing.

This takes many forms. The most obvious and understandable being *supply
all the paths the server knows about to the client*.

Clients that don't do "insecure AIA fetching" (as Martin likes to
pejoratively phrase it, as I disagree with him on this point
substantially), but that thankfully don't implement Martin's strict
checking (which luckily, few do), this works as a viable means of
providing acceptable paths to them. At the cost of violating the TLS RFC
in a part of language that *enforcing* requires more work and introduces
more security issues to clients.

If every client had RFC 4158 capable path discovery, would I still
advocate relaxing the language? Honestly, yes, because it should be up to
the server to balance the tradeoffs between client interoperability. If
every client enforced the TLS requirements, as Martin advocates, it would
directly and concretely harm the ability to push for reform in the PKI
system used by the most prominent deployment of TLS (the HTTPS Web),
because clients that lack "insecure AIA fetching" would simply break when
the Web PKI changes.

There are many ways to mitigate this, and luckily, modern cryptographic
libraries are starting to see the wisdom that Microsoft saw nearly 10
years ago, when they made CryptoAPI automatically update the trust store
and handle trust migrations. However, in an IoT world, where things are
using libraries like OpenSSL, and which lack RFC 4158 path discovery, I'm
increasingly concerned that we will see greater ossification and
calcification of the PKI stores, preventing much needed security reform.

So yes, I do see this current language as objectively and quantifiably BAD
for security. I think implementing it in a TLS client library (since it is
NOT required of PKI libraries or implementations, and RFC 4158 rightly
dissuades it) introduces more attack surface and more complexity for
negative gains on security and maintainability.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 11 May 2015 18:55:15 +0000

I agree with Ryan on this. It would be awesome to be able to keep certificate_list ordering simple, but in reality we can't, for the reasons Ryan eloquently presented.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Ryan Sleevi
Sent: Monday, May 11, 2015 11:42 AM
To: Salz, Rich
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

On Mon, May 11, 2015 11:20 am, Salz, Rich wrote:
>  We already have non-compliant behavior, even though the spec is 
> pretty  clear and some implementations rely on compliance with that 
> spec. And  nobody has said that it's a BAD requirement, just that it's 
> not  universally implemented.

That's not true. I've explicitly stated it's a BAD requirement, and tried to give concrete examples.

I'll be explicit:

1) I think clients, such as Martin's, that implement normative checking of ordering and are used for the Internet at large (e.g. between servers and clients that are not controlled by a single entity) are bad for Internet security.
2) I think clients, such as Martin's and Geoff's, that do not implement RFC 4158 path discovery are bad for Internet security.
3) I think language that encourages or requires clients to normatively enforce such ordering are bad for Internet security.

So to be clear, I disagree with my colleague, Ben Laurie, rather substantially here.

The context is that:
1) I'm involved in maintaining one of the largest client web browsers' PKI stack. Thus, I deal with brokenness on a daily basis.
2) I'm involved in dealing with the PKI stacks of a variety of platforms, some open-source, some closed-source, and with a variety of versions.
3) I'm involved in the CA/Browser Forum and have spent the past several years trying to work in deprecation of insecure cryptography (in the case of certificates, SHA-1, RSA signatures <= 1024-bits, and in general, RSA signatures vs ECC)

I say all this to say "I've seen things", and when it comes to gross hacks, few people are as more affected and have more visibility to them than those doing things similar to me.

In my original email, I tried to establish why:
1) Clients have disparate trust-stores. Absent the X.500 directory, this is a fact of life. The set of trust anchors recognized by Microsoft will and is different than those recognized by Mozilla, for a variety of legitimate reasons that will not change, no matter what the IETF does.
2) As such, there is no single trusted path. RFC 4158 spells this out in abundant detail, and the figures contained should be "required skimming"
for any of this discussion.
3) Implementing path discovery is hard. RFC 4158 spells out why. It's also necessary, as the first two points here spell out. Clients that don't support RFC 4158 "break" if a trusted path cannot be found.

In order to handle deprecations of SHA-1, for example, certificate paths need to be replaced with their SHA-256 equivalent. To handle the deprecation of RSA-1024 bit, alternative paths must be supplied. To handle the deprecation of RSA in favour of ECC, alternative paths must be supplied.

When clients break, servers have to choose between breaking clients and doing the right thing or keeping clients working.

So servers do the sensible thing. They try to find a way to keep clients working WHILE doing the right thing.

This takes many forms. The most obvious and understandable being *supply all the paths the server knows about to the client*.

Clients that don't do "insecure AIA fetching" (as Martin likes to pejoratively phrase it, as I disagree with him on this point substantially), but that thankfully don't implement Martin's strict checking (which luckily, few do), this works as a viable means of providing acceptable paths to them. At the cost of violating the TLS RFC in a part of language that *enforcing* requires more work and introduces more security issues to clients.

If every client had RFC 4158 capable path discovery, would I still advocate relaxing the language? Honestly, yes, because it should be up to the server to balance the tradeoffs between client interoperability. If every client enforced the TLS requirements, as Martin advocates, it would directly and concretely harm the ability to push for reform in the PKI system used by the most prominent deployment of TLS (the HTTPS Web), because clients that lack "insecure AIA fetching" would simply break when the Web PKI changes.

There are many ways to mitigate this, and luckily, modern cryptographic libraries are starting to see the wisdom that Microsoft saw nearly 10 years ago, when they made CryptoAPI automatically update the trust store and handle trust migrations. However, in an IoT world, where things are using libraries like OpenSSL, and which lack RFC 4158 path discovery, I'm increasingly concerned that we will see greater ossification and calcification of the PKI stores, preventing much needed security reform.

So yes, I do see this current language as objectively and quantifiably BAD for security. I think implementing it in a TLS client library (since it is NOT required of PKI libraries or implementations, and RFC 4158 rightly dissuades it) introduces more attack surface and more complexity for negative gains on security and maintainability.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 11 May 2015 21:23:05 +0000

> That's not true. I've explicitly stated it's a BAD requirement, and tried to give

Thanks for taking the time to write all that up.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 12 May 2015 01:51:43 +0000

> That's not true. I've explicitly stated it's a BAD requirement, and tried to give

Okay, you have convinced me.  Thanks

---

From: Ben Laurie <[email-masked]>
Date: Tue, 12 May 2015 13:37:14 +0100

> So to be clear, I disagree with my colleague, Ben Laurie, rather

To be fair, I mostly, or maybe even completely, agree with you on
further thought. I just wish that path validation were less
complicated!

I still have a concern around servers that are missing certificates
that are needed to complete validation at all, which the proposed
language change would permit.

I agree that the supplied certs have to cover multiple possible
validation paths, and hence cannot follow a strict "each cert
validates the next" ordering.

It would be nice, however, to put an end to the current chaos.

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 15:14:53 +0200 (CEST)

> clients that are not controlled by a single entity) are bad for Internet

Huh?  I never described anything like that "normative checking".

My client simply feeds the certificate chain from the TLS Certificate
handshake message, up to an issure that is recognized as trust anchor
directly into the certificate path validation function (rfc5280,
section 6.1) just like rfc5246 and rfc5280 _designed_ this to be.

> RFC 4158 path discovery are bad for Internet security.

rfc4158 is a pretty complex and dumb idea. AND, it is *NOT* a standard.
It is explicitly ignored by PKIX (rfc5280). 

btw. there is *NO* secure approach described for path discovery in
rfc4158.  So if you do not have a prepopulated local store with
all intermediate certs, it can not possibly work in a secure fashion
(and a universal, trusted, omniscient directory which can be securely
 accessed is non-existent).

> enforce such ordering are bad for Internet security.

You are misreading the existing language.  What has been written, applies
to the *SENDER* of the Certificate handshake message, not to the recipient.
As previously described, the purpose is to make the job of verifying
the server certificate easy for the recipient.

> legitimate reasons that will not change, no matter what the IETF does.

Correct.  Not a problem with the existing text.

> for any of this discussion.

The existing requirements do *NOT* say that there can only be one trusted
path.  It is up to the server to decide which path to send.  If there
are multiple possible pathes, the choice of which particular path the
server sends will have an impact on interoperability, because not all
clients might be able to verify all paths.

> support RFC 4158 "break" if a trusted path cannot be found.

Implementing rfc4158 will pretty much always result is serious security
problems (or an unmanagable monster).

rfc4158 is not a standard and actively ignored by rfc5280, so it is
not even part of the Internet Security Architecture.

> the deprecation of RSA in favour of ECC, alternative paths must be

Not at all.  Whether the server uses a ECDSA certificate instead of
an RSA certificate is determined by the cipher suite that the server
chooses (ECDHE_ECDSA vs ECDHE_RSA), so the path has been determined when
the Server's certificate handshake message needs to be composed.

But noone with a security clue would be using ECDSA for online signatures.
And doubly so, not with NSA-backdoored curves.

> more security issues to clients.

You're putting words in my mouth that I certainly never said.

The current language applies *ONLY* to the sender of the Certificate
handshake message.  It does not require any particular behaviour for
the client to verify the server certificate.

Which kind of certificate path discovery are you thinking of?
Forward/upward AIA chasing is a formally provable security problem.
Web Browsers may not care about this, because the aggressively
execute active content received over insecure channels all the time,
and perform millions of requests without consent from the user and
entirely careless about the security implications.  non-negligent
programmatic TLS clients are different, and so are non-negligent servers.

> every client enforced the TLS requirements, as Martin advocates,

I'm not, and never did advocate for a specific client behaviour.

The existing text is purely about requirements on the *SENDER* of the
Certificate handshake PDU.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Tue, 12 May 2015 06:58:47 -0700

> section 6.1) just like rfc5246 and rfc5280 _designed_ this to be.

How does the server know which trust anchors will be accepted,
particularly in cases involving cross-validation?

>  accessed is non-existent).

Let's look at actual code implementing this "complex and dumb idea".
https://golang.org/src/crypto/x509/verify.go What security property is
violated by this code, as a result of implementing RFC 4158?

Of course, I'm not saying this idea isn't complex and dumb. It has
exponential complexity in some cases, may encode 3-SAT (I've been
thinking hard about how to do that, and have some ideas involving path
constraints) etc, etc. But it's a unfortunate result of how badly PKIX
is designed that something like this becomes necessary. The
restriction in RFC 5280 won't function in many reasonable scenarios.

Or are you saying that cross-validation doesn't exist, that all
clients have the same root stores, so we don't need it anyway, and
that we can use multiple chains for the cases of algorithm
depreciation?
> clients might be able to verify all paths.

How does the server know which path a client that connects to it will trust?

> the Server's certificate handshake message needs to be composed.

That only determines which leaf was used. It's of course true that one
could provide two separate paths, and have servers pick between them
based on the leaf. Is that how you propose we deal with this problem?

> And doubly so, not with NSA-backdoored curves.

I didn't know you were an algebraic geometer, or a cryptographer. What
security problem does ECDSA have when used online? P256 is backdoored
how again?

> programmatic TLS clients are different, and so are non-negligent servers.

What exactly is the issue here? I'm not familiar enough with AIA to
understand what you think people do and why you think it is a problem.
If you could actually explain the problems, preferably with example
exploits, it would be appreciated.

Sincerely,
Watson Ladd

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 12 May 2015 16:48:56 +0200

> RFC 4158 path discovery are bad for Internet security.

That is of course if you define Internet as the web, and "security" as
the web PKI. What you are in fact describing is a failure of the web PKI
which RFC 4158 makes apparent. When you define trust as "anything my
browser trusts", then indeed you are going to have trust issues once you
switch to a browser from a different vendor. Nevertheless, RFC 4158 is
far from being a standard (just an informational RFC), and there are
standard's track extensions which can address the issue [0] and can
allow the server to decide which path to send. Does your good for
Internet implementation utilize it?

regards,
Nikos

[0]. https://tools.ietf.org/html/rfc6066#section-6

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 12 May 2015 10:13:26 -0700

On Tue, May 12, 2015 7:48 am, Nikos Mavrogiannopoulos wrote:
>  Nevertheless, RFC 4158 is
>  far from being a standard (just an informational RFC),

I don't think I presented it as a standard - just what the major PKI
clients that most users interact with on a daily basis do.

I didn't suggest it was the whole Internet. But for the PKI that people
rely on for their daily interactions online (aka the Web PKI), which is
used far beyond *just* web browsers (as
https://access.redhat.com/articles/1413643 reminds us), the security here
is relevant, and perhaps essentially so.

>  and there are

There are no plans at present to implement, and it's unlikely we would.
Without wanting to get into a separate discussion, the privacy and
performance implications of such an extension are extremely undesirable.

Just because there's a Standards Track I-D doesn't mean it is wise or
desirable ( http://tools.ietf.org/html/rfc6961 is another example), and
just because it's an Informational Draft doesn't mean it's not widely
supported (CryptoAPI, Java, and NSS, for example, all follow the logic of
4158)

If I phrased your concern more objectively, would ubiquitous support
"tomorrow" for RFC 6066 cause me to remove support for relaxing the
language? No, because we still have the world we live in today. And having
spec language reflect an idealized, unrealistic future instead of the
reality we live in just does more harm than good. Much like references to
the X.500 Global Directory.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 12 May 2015 10:40:28 -0700

>  Huh?  I never described anything like that "normative checking".

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

This, in context, and combined with your follow-up qualifiers, suggested a
level of checking beyond RFC 5280.

>  It is explicitly ignored by PKIX (rfc5280).

Only to the extent that RFC 5280 Section 6 deals specifically with the
validation of a given certification path, while leaving out of scope (but
acknowledged rather extensively throughout the documentation, especially
for extensions) the building/discovery of said paths.

Indeed, Section 3.2 calls out some of the complexities and acknowledgement
that inherent in the PKI is the possibility of multiple certification
paths. Section 6.2 further acknowledges this.

Merely I think it's a mistake and misleading to suggest that RFC 4158 is
an interesting side-note in the history of PKI, when in fact it describes
the behaviour of some of the largest (by end-user) clients out there
(Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's
JCA/CertPath APIs).

>   accessed is non-existent).

Probably not for the TLS list, but since you bring this up virtually every
time when discussing PKI issues, it may help if you actually write up the
threat model or where you see it as "not secure". I see Watson has equally
requested this.

It's probably not suitable for the PKIX WG (given the impeding/actual shut
down - I can't remember timelines), but I think it'd be useful for the
community at large, and separate from the TLS WG, for you to actually
elaborate on this claim.

>  clients might be able to verify all paths.

I think this is the heart of the matter.

The current language forces a choice for server operators that is often
untenable - reject a set of valid clients, who COULD work, in order to
preserve spec purity that few clients enforce explicitly.

The proposed language change reflects the reality - that when options
exist that require a server operator to choose between, say, 25% of their
clients working while respecting the spec, 50% of their clients working
while respecting the spec, or 70% of their clients working while ignoring
the spec, they will choose the 70%, even if it means violating the spec.

(As to why 70 < 50 + 25, let's pretend, for sake of discussion, that 5% of
the clients behave like yours and enforce a strict ordering, either
implicitly by only using an RFC 5280 algorithm, or explicitly by imposing
such a requirement during the TLS handshake)

>  the Server's certificate handshake message needs to be composed.

This was not the issue I was referring to; you can have an ECC leaf issued
off an RSA intermediate or root. Indeed, this is not at all uncommon, and
while decrying it probably won't be useful for this thread, we should at
least acknowledge it.

There are a variety of business and operational reasons that led to this,
but there are situations in which a given CA may have an ECC root
recognized in one set of clients, and an RSA root recognized in a set of
other clients, and thus again, multiple paths exist.

And I'm further setting aside the issues between ServerKeyExchange
authentication vs Server Certificate authentication, which is a whole host
of other worms w/ the existing SignatureAndHashAlgorithms. That's its own
issue that I'm not wanting to dive into.

>  But noone with a security clue would be using ECDSA for online signatures.

...

>  And doubly so, not with NSA-backdoored curves.

...

Such incredible claims that I'm going to have to leave them unaddressed,
as apparently I and my colleagues are not true Scotsmen.

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 20:54:10 +0200 (CEST)

> level of checking beyond RFC 5280.

Actually, no, I never did suggest anything like that.
I'm simply following standards in an obvious and straightforward fashion.

The relevant snippets from PKIX rfc5280, section 6:

>From Section 6.2  Using the Path Validation Algorithm:

                             While each certification path begins with
   a specific trust anchor, there is no requirement that all
   certification paths validated by a particular system share a single
   trust anchor.  The selection of one or more trusted CAs is a local
   decision.  A system may provide any one of its trusted CAs as the
   trust anchor for a particular path.  The inputs to the path
   validation algorithm may be different for each path.

The inputs to the "Basic Path Validation" algorithm in rfc5280, section 6.1
are described with:
   https://tools.ietf.org/html/rfc5280#page-73

   To meet this goal, the path validation process verifies, among other
   things, that a prospective certification path (a sequence of n
   certificates) satisfies the following conditions:

      (a)  for all x in {1, ..., n-1}, the subject of certificate x is
           the issuer of certificate x+1;

      (b)  certificate 1 is issued by the trust anchor;

      (c)  certificate n is the certificate to be validated (i.e., the
           target certificate); and

      (d)  for all x in {1, ..., n}, the certificate was valid at the
           time in question.

   A certificate MUST NOT appear more than once in a prospective
   certification path.

   When the trust anchor is provided in the form of a self-signed
   certificate, this self-signed certificate is not included as part of
   the prospective certification path.  Information about trust anchors
   is provided as inputs to the certification path validation algorithm
   (Section 6.1.1).

Since the TLS Certificate handshake message is *REQUIRED* to supply
the certificate chain in order, it is only necessary to determine
whether any issuer(!) on that list of ordered certificates is recognized
as a locally available trust anchor, and then provide that trust
anchor plus the certificates up to the one issued by the recognized
trust anchor straight to the "Basic Path Validation" function.

> for extensions) the building/discovery of said paths.

X.509 would require an omniscient trusted directory to perform certificate
path discovery, and the Certificate Path Validation algorithm in
rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
approach for certificate path discovery, because this approach would
be clearly insecure and irresponsible.

> (Windows' CryptoAPI, Mozilla's NSS in various flavours, Java's

Sounds like plenty of security holes to exploit and many frantic patch
days to come.

-Martin

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 12 May 2015 12:16:13 -0700

>  be clearly insecure and irresponsible.

Again, Martin, you're making unsubstantiated and inaccurate claims.

To the extent it's relevant to the discussion for the TLS WG, I will
simply note that RFC 5280 does not say anything about path discovery
precisely because discovery is out of scope for validation. Validation is
consistent, while discovery depends on a myriad of cases and protocols
outside of the narrow view of TLS. e.g. the validation of certificates in
PKCS#7 or in S/MIME.

So yes, RFC 5280 doesn't discuss how to do path discovery, because it's
out of scope, even though it repeatedly describes extensions and options
for how to do path discovery *that rely on parsing the untrusted
certificate*

RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges
it exists precisely to make discovery possible.

However, to the points at hand, at least it establishes why you object to
the change. You view it as predicated upon a fundamentally insecure
algorithm. While I (and many others, as evidenced by implementation and
discussion) would disagree with you, and I personally feel your claims of
standards imprimatur to be lacking, it at least provides a clear rationale
for your disagreement.

I don't think it'd be helpful for consensus building for me to try and
demonstrate where I think even RFC 5280 would disagree with your
conclusions, but if others feel themselves swayed by Martin's arguments, I
would be happy to add that fuel to the discussion.

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 21:29:50 +0200 (CEST)

> for how to do path discovery *that rely on parsing the untrusted

*Parsing* an untrusted certificate is not the problem.

But doing _more_ than comparing contents to something you trust is
where the security problem starts.  

> it exists precisely to make discovery possible.

With the prerequisite of a conscious and informed active consent by a human
administrator during out-of-band maintenance/administration, using AIA to
download a certificate can be an accetable security trade-off.

But a machine/automata/algorithm that will automatically download objects
from URLs from still-untrusted data provided by the peer is definitely
insecure and irresponsible.

> would be happy to add that fuel to the discussion.

I'm still waiting for an example why you would need to send junk in
the Certificate handshake message, which could not be avoided by the
offending CAs issuing proper crossCAs instead.

-Martin

---

From: Yoav Nir <[email-masked]>
Date: Tue, 12 May 2015 22:52:47 +0300

> insecure and irresponsible.

In that sense, how is AIA different from revocation checking? Whether you use CRLs or OCSP, you’re following a URL in the (still untrusted or at least possibly revoked) certificate to retrieve an object.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 May 2015 16:03:36 -0400

> insecure and irresponsible.

Doesn't this argument suggest that we should go ahead and relax the text
as suggested?

If:

 * automated cert fetching is bad (i'm inclined to agree with you about
   this, Martin, since it would embed www-like promiscuous network
   activity in protocols that don't currently suffer from it), and

 * cert validation is hard (as evidenced by the litany of problems
   people have getting it right), and

 * no unified/global trust anchor exists (because people have different
   perspectives on the world), and

 * servers don't know what the clients preferred trust anchors are (and
   probably shouldn't require the client to announce this perspective to
   perform a TLS handshake, for privacy reasons), and

 * we need to be able to upgrade existing PKI smoothly, because breaking
   existing clients will prevent most deployers from ever upgrading
   anything,

Then:

 * it seems like we ought to explicitly permit servers to ship the
   certificates capable of forming multiple verification chains in the
   TLS handshake, so that clients have all the certs they need to find
   their preferred path, without having to do AIA fetching.

Given that servers *already do this*, the argument seems even stronger.

I agree with Martin that this is super-dirty and a far more complex
system than anyone sane would have designed from first principles.  But
i still think it's the right thing to do given the ugly state of the
network today.

     --dkg

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 12 May 2015 20:37:15 +0000

I do not have objections to server sending a certificate bag so that one or more paths can be formed/built/discovered by the client.

However, I disagree with several things Martin says about AIA chasing and RFC 4158.  To me, most of what he says has been argued on PKIX and I do not see any security concerns.  While one can argue that SIA chasing is ideal since your next step is always from a vetted pointer, as others have pointed out CRL DP and OCSP situation is no different.  If the AIA pointer has poisoned data in it, you will not decode the certificate or the certificate bag correctly.

Besides in a cross-certified world, a server has one view of the trust anchors and a client might reside in cross-certified domain, necessitating AIA chasing on some CA certificate at some point.  If you like, clients can do SIA chasing, but not many folks implement SIA on the producer side (i.e., the CAs) or on the consumer side (i.e., the TLS client).  In that scenario, there would be no need for the server to send certificate chain or bag; simply server certificate will suffice.

BTW, while not related to validating the server certificate, some of the popular browsers have had issues in the area of client authenticated TLS, where the browser will not even present a legitimate client certificate since it terminates on a trust anchor from the browser's perspective and that trust anchor not being in the server's hints list, albeit server can build a path to the client certificate.  Again, this is endemic to cross-certified environments.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, May 12, 2015 4:04 PM
To: [email-masked]; [email-masked]
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

On Tue 2015-05-12 15:29:50 -0400, Martin Rex wrote:
> With the prerequisite of a conscious and informed active consent by a 
> human administrator during out-of-band maintenance/administration, 
> using AIA to download a certificate can be an accetable security trade-off.
>
> But a machine/automata/algorithm that will automatically download 
> objects from URLs from still-untrusted data provided by the peer is 
> definitely insecure and irresponsible.

Doesn't this argument suggest that we should go ahead and relax the text as suggested?

If:

Then:

I agree with Martin that this is super-dirty and a far more complex system than anyone sane would have designed from first principles.  But i still think it's the right thing to do given the ugly state of the network today.

     --dkg

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 22:51:30 +0200 (CEST)

Yoav Nir wrote:
[ Charset UTF-8 unsupported, converting... ]
> In that sense, how is AIA different from revocation checking?
> Whether you use CRLs or OCSP, you?re following a URL in the
> (still untrusted or at least possibly revoked) certificate
> to retrieve an object.

Possibly revoked?  yes.

Untrusted? *NO*.  Look at the algorithm in rfc5280 again.

https://tools.ietf.org/html/rfc5280#section-6.1.3

   6.1.3. Basic Certificate Processing

   The basic path processing actions to be performed for certificate i
   (for all i in [1..n]) are listed below.

      (a)  Verify the basic certificate information.  The certificate
           MUST satisfy each of the following:

         (1)  The signature on the certificate can be verified using
              working_public_key_algorithm, the working_public_key, and
              the working_public_key_parameters.

         (2)  The certificate validity period includes the current time.

         (3)  At the current time, the certificate is not revoked.  This
              may be determined by obtaining the appropriate CRL
              (Section 6.3), by status information, or by out-of-band
              mechanisms.

         (4)  The certificate issuer name is the working_issuer_name.

-Martin

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 May 2015 21:08:31 +0000

> Given that servers *already do this*, the argument seems even stronger.

I don't know which clients choke on bags/heaps of certificates
rather than linear chains.  OpenSSL tolerates a heap.  However, as
mentioned previously for OpenSSL clients, the heap contains an
equivalent chain that works equally well for those clients.

Thus one can take a middle ground, where servers are allowed to
send non-chains (heaps/bags/...), but clients are *not* required
or expected to try all possible paths.  To the extent that some
clients try multiple paths, the server operator may benefit from
such a configuration, but various clients will build some single
path out of the heap and either succeed or fail with that.

Allowing servers to send a heap seems mostly harmless, provided
we're not also *requiring* clients to do the full combinatorial
explosion path construction.  If the extent of the change is
to allow mutually consenting clients and servers to play that
game, I have no objections.  

That does of course introduce possible harm to clients that simply
don't work when given a heap even to the extent of building a single
candidate chain.  No idea whether such clients are a significant
obstacle.

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 May 2015 00:11:44 +0300

> On May 12, 2015, at 11:51 PM, Martin Rex <[email-masked]> wrote:
> 
> Yoav Nir wrote:

In case a CA mis-issues a certificate, such as when giving someone who is decidedly not Microsoft a certificate for www.microsoft.com, what it should do is to revoke that certificate. That’s the only way to un-emit the certificate other than patch all relying parties. So as long as you haven’t checked revocation, the certificate is not only potentially revoked (someone stole my private key), it’s also potentially mis-issued. 

I think the section you quote below says that. You haven’t done path validation until you’ve checked revocation for every certificate.

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 May 2015 17:23:30 -0400

> game, I have no objections.  

The current proposal is that implementations SHOULD support lists
that are not strictly linear, but not MUST. Implementations would
still be permitted to reject cert lists they can't handle, for whatever
reason.

Dave

---

From: [email-masked] (Martin Rex)
Date: Tue, 12 May 2015 23:46:00 +0200 (CEST)

Viktor Dukhovni wrote:
> explosion path construction.

To the contrary, allowing servers to send a heap is the opening of
a rotten can of worms.

Next you see defective clients use that as an excuse for not fixing
e.g. their lack of recognizing a trust anchor when it is included
as crossCA variant in the certificate_list.

Next you see the users of particular broken, unfixed clients asking
why they can not configure a particular heap of junk, to cater their
broken clients, with a particular perfectly correct TLS implementation
(that properly encodes only a linear list of certificates into
certificate_list).

Really, with the proposed change, the shit already hits the fan.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 May 2015 00:30:34 +0200 (CEST)

Yoav Nir wrote:
> 
>> Martin Rex <[email-masked]> wrote:
>> 
>> Yoav Nir wrote:
>>> 
> In case a CA mis-issues a certificate, such as when giving someone
> who is decidedly not Microsoft a certificate for www.microsoft.com,
> what it should do is to revoke that certificate.

Yes.  So what?  When you use the AIA OCSP or CRLDP information
from a certificate during certificate path validation, you do this only
after you have verified the CA signature on the certificate, which confirms
that the CA placed this information in the certificate.

Whether the entity who controls the private key is really the one who
the CA thought he was or whom the Subject/SAN identifies, is not yet
relevant.

>
> That's the only way to un-emit the certificate other than patch all
> relying parties. So as long as you haven't checked revocation,
> the certificate is not only potentially revoked (someone stole my
> private key), it's also potentially mis-issued. 

Correct.  but the issues that you listed do not make the OCSP responder
location and CRLDP info within that certificate untrustworthy.

In case that you wonder what happens if a CA is more throughly compromised,
i.e. that someone manages not only to get certs mis-issued under a false
identity, but also with arbitrary attributes in them -- well, this is
something that the folks who invented X.509 claimed that it can not
possibly happen, because they did not design their approach to distribute
the CRL&OCSP distribution info to account for this (or they would have had
to distribute this information through the CA certificate rather than
through the end-entity certificate.

If you have or suspect that kind of CA breach (e.g. DigiNotar), then your
only course of action is to immediately and completely nuke the entire PKI
(i.e. revoke the CA certificate, respond to all issuer&serial requests
for that issuer to your OCSP responder with "revoked".

> 
> I think the section you quote below says that.
> You haven't done path validation until you've checked revocation
> for every certificate.

I believe the enumeration to be an _ordered_ list, because it uses
numbers rather than bullets.  I realize that there are folks who have
issues with doing stuff properly "in order".

Now there is one obvious defect in that list/order.
item number (4) should really be number (1).  This is not
a security issue to do (4) last rather than first, but it is
an obvious usability issue to anyone with experience in customer
support.

In the wild, you will often find cause that are non-malicious
why an out-of-order certificate chain finds its way into the
Basic Path Validation function.  I assume that the weird TLS servers
that Ryan is setting up send their bogus heaps of certs with non-malicious
intent.

If that happens for the below ordering of operations

 - you needlessly waste lots of CPU cycles in a asymmetric crypto operation
   that will predictably fail

 - you will typically get an error that says "digital signature verification
   failure", because a digital signature verification fails here.

 - this failure will typically preempt all further checking, and the
   fact that working_issuer_name differs from the issuer of the current cert
   may get totally lost.

When doing customer support, it is vital to know that a certificate path
validation failure happend because the peer sent junk instead of a well-formed
certification path in the TLS Certificate handshake message, and that
the digital signature verification failure is not a data corruption or
attack.

-Martin

---

From: Fabrice Gautier <[email-masked]>
Date: Tue, 12 May 2015 16:04:05 -0700

> particularly in cases involving cross-validation?

Isn't that the purpose of the "Trusted CA Indication" extension in RFC 6066 ?

I don't know of anything implementing it though....

-- Fabrice

---

From: Brian Smith <[email-masked]>
Date: Tue, 12 May 2015 14:28:04 -1000

Yoav Nir <[email-masked]> wrote:

> In that sense, how is AIA different from revocation checking? Whether you
> use CRLs or OCSP, you’re following a URL in the (still untrusted or at
> least possibly revoked) certificate to retrieve an object.
>

When you fetch CRLs or OCSP responses, you are using a URL that has been
authenticated by a trusted issuer, assuming you do revocation checking from
the root to the end-entity, which is the safer way of doing it. Whereas, in
AIA cert fetching you are making a request to an unauthenticated URL. That
is quite a big difference, because it is much harder to get a CA to sign a
certificate with your chosen OCSP URL than it is to just forge your own
certificate with whatever AIA caIssuers URL you want to have.

Ultimately, a client shouldn't fetch OCSP responses or CRLs either, for
many reasons. One of the big reasons is that those fetches greatly increase
the attack surface of the client beyond what is otherwise necessary.
Instead we need to move to a model where revocation information is always
provided within the TLS handshake (e.g. OCSP stapling and/or short-lived
certificates).

Consequently, we shouldn't accept AIA cert fetching as good or even
reasonable behavior based on analogies to revocation information fetching.

Cheers,
Brian

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 May 2015 08:58:54 +0300

> On May 13, 2015, at 3:28 AM, Brian Smith <[email-masked]> wrote:
> 
> Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> When you fetch CRLs or OCSP responses, you are using a URL that has been authenticated by a trusted issuer, assuming you do revocation checking from the root to the end-entity, which is the safer way of doing it. Whereas, in AIA cert fetching you are making a request to an unauthenticated URL. That is quite a big difference, because it is much harder to get a CA to sign a certificate with your chosen OCSP URL than it is to just forge your own certificate with whatever AIA caIssuers URL you want to have.
> 
> Ultimately, a client shouldn't fetch OCSP responses or CRLs either, for many reasons. One of the big reasons is that those fetches greatly increase the attack surface of the client beyond what is otherwise necessary. Instead we need to move to a model where revocation information is always provided within the TLS handshake (e.g. OCSP stapling and/or short-lived certificates).
> 
> Consequently, we shouldn't accept AIA cert fetching as good or even reasonable behavior based on analogies to revocation information fetching.

I see. I understand the difference, I just don’t think it matters. I also disagree with your assertion that clients shouldn’t fetch OCSP responses, CRLs or AIAs. Sending stapled OCSP responses or an entire certificate chain is a good optimization and makes the TLS handshake end more quickly. I can see why people would like that. But fetching these things from the Internet is no different from fetching other items from the Internet. Clients do this all the time.

I agree that this increases the attack surface, but what kinds of attacks are we talking about? A very mild DoS attack by pointing the client at a URL with a petabyte of random data? An invalid CRL? A badly formatted CA certificate that will cause a buffer overflow on the client?  That kind of certificate could have been sent in the handshake. These risks seem to me to be part life on the Internet. They’re not worth the issues of sending large objects over UDP for DTLS for example.  So I agree that for regular TLS sending the entire chain is the right thing to do, as is sending a stapled OCSP response. I just don’t think building a chain through other means is in any way “bad”. 

Yoav

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 13 May 2015 06:23:28 +0000

On Wed, May 13, 2015 at 08:58:54AM +0300, Yoav Nir wrote:

> So I agree that for regular TLS sending the entire chain is the right
> thing to do, as is sending a stapled OCSP response. I just don't think
> building a chain through other means is in any way "bad".

It can be at least onerous.  Clients speaking a given protocol may
not be at liberty to connect to anything other than their peer,
and may not posess an HTTP stack with which to make out-of-band
requests.

The SSL/TLS library cannot transparently attempt such additional
connections with consent and mediation for connection establishment
and event loop integration from the application layer to engage in
the additional communications.

So in-band is definitely simpler, and leaks less data to third
parties.

-- 
	Viktor.

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 13 May 2015 12:55:22 +0000

I agree with Yoav.

From: TLS [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Wednesday, May 13, 2015 1:59 AM
To: Brian Smith
Cc: [email-masked] ([email-masked])
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

On May 13, 2015, at 3:28 AM, Brian Smith <[email-masked]<mailto:[email-masked]>> wrote:

Yoav

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 May 2015 20:12:13 +0200 (CEST)

Yoav Nir wrote:
> 
>> Brian Smith <[email-masked]> wrote:
>> 
>> authenticated by a trusted issuer, assuming you do revocation checking
>> from the root to the end-entity, which is the safer way of doing it.
>> Whereas, in AIA cert fetching you are making a request to an
>> unauthenticated URL. That is quite a big difference, because it is
>> much harder to get a CA to sign a certificate with your chosen OCSP URL
>> than it is to just forge your own certificate with whatever
>> AIA caIssuers URL you want to have.
>>   [...]
> I see. I understand the difference, I just don?t think it matters.
>   [...]
> I agree that this increases the attack surface, but what kinds of
> attacks are we talking about?

In the TLS WG, we do not need to defer PKIX specifications for dangerous
behaviour, because such behaviour was already proposed in the very first
TLS extensions document (rfc3546), and equipped with security considerations
that give a glimpse at the attackers vast possibilities from such a facility.

https://tools.ietf.org/html/rfc3546#section-6.3

-Martin