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

["Ryan Sleevi" <[e-mail]>]

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.