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

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:tls-bounces@ietf.org] On Behalf Of Ryan Sleevi
Sent: Monday, May 11, 2015 11:42 AM
To: Salz, Rich
Cc: TLS@ietf.org (tls@ietf.org)
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:
> > 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.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls