On Thu, Dec 5, 2019 at 10:42 AM Nick Lamb wrote:
> On Wed, 4 Dec 2019 17:12:50 -0500
> Ryan Sleevi via dev-security-policy
> wrote:
>
> > Yes, I am one of the ones who actively disputes the notion that AIA
> > considered harmful.
>
> As not infrequently happens I can't agree with Ryan here. AIA chasing in
> browsers is a non-trivial privacy leak AND doesn't match how the
> specification says things work.
>
Wait, what? Is this a reference to TLS? Certainly not 5280.
> What I'd like to see, as with OCSP stapling, is for web /servers/ to
> do the fix-up not browsers. If an operator doesn't take the initiative
> to provide the server with a complete chain, it should do its own AIA
> chasing to discern the chain and then provide that chain in the TLS
> Certificate message. This obeys the specification AND makes the server
> software easier to administrate AND has few or no privacy implications
The problem, again, is that the notion of "the chain" and "a complete
chain" is a flawed assumption. This is the flaw in Ben's argument, and it's
the flaw due to the flexibility browsers afford CAs in how to design and
structure their PKI, *and* the flaw that not all browsers (or all versions
of a given browser) support the same CA.
This is trivial to work out on paper to see why the notion of "the chain"
is flawed, and because it's flawed, the server cannot do the right thing.
Further, even if we were assume to ascribe to servers the responsibility,
it would mean that clients (like browsers) could not make pro-user changes
unless/until servers updated.
Assuming you have a CA A, which signs intermediate B, which signs leaf C
A -> B -> C
Naively, or without thinking through the implications, people want servers
to send "C, B" in the TLS handshake, and let the client know it has A.
However, what happens when the CA A creates a new root, with stronger
cryptography, called D? They typically do one of the following:
D -> A -> B -> C (New root signs old root, to keep old certs working)
A -> D -> E -> F (Old root signs new root, which creates a new issuance,
where F is the leaf, E is the new stronger intermediate. Think SHA-2
migrations here, where A/B/C is SHA-1 and D/E/F is SHA-2)
A -> B -> C / D -> B' -> C (a new version of B, called B', is created,
signed by D)
[or some combination of the above]
The moment you've done this, there's no longer 'the' chain. The server that
was previously sending "C, B" is now buggy to the browser that only trusts
D, because it doesn't know about A (and thus, can't go "C, B, A" to find
D). The server that was sending "F, E" is buggy to clients that trust A,
even though it's perfectly configured to clients that trust D, because
clients that only trust A don't know how to go "F, E, D" to get to A. The
server that has to decide between B and B' is just... doomed.
Now, intermediate preloading helps here, but only to a degree.
Name-constrained sub-CAs aren't required to be disclosed by Mozilla, for
example, nor the subordinates they issue, and so intermediate preloading
won't cover those cases, and the problem still exists all the same. Maybe
the answer is "don't do name-constrained CAs" or "require their
disclosure", and that's not unreasonable, but a significant amount of
policy work (since the primary reason for name-constraining is to reduce
the responsibility and management overhead)
>From an ecosystem health perspective, we know not every client supports
root auto-updates. Even Mozilla clients don't, but this is especially
pronounced on non-Windows platforms (... including Apple). The existence of
AIA helps keeps all of this "working" - working with modern and working
with legacy. Intermediate preloading helps, but only by making the software
vendor eat the cost of the flexibility afforded to the CA, which... is
unfortunate.
>From looking at better security, the 'ideal' path is that modern clients
are only trusting modern (new) roots, which never issued old crappy certs.
That is, the path "D -> A -> B -> C" is forbidden, while the path "A -> D
-> E -> F" is required. Further, if you want to excise past crappy certs, a
modern browser would require a new root from a CA every few years, such
that today's "A -> D -> E -> F" becomes tomorrow's "A -> D -> G -> H -> I"
- where "G -> H -> I" is the path that conforms to all the modern security
(G will have only issued certs that are modern), while D and A are legacy
paths for old clients. In order to keep old clients working, a precondition
to browsers doing the modern security thing, you need for *old* clients to
be able to get to D/A. And you don't want to send (in the TLS handshake)
"I, H, G, D" to cover all your permutations - that is terrible for
performance *and* security (e.g. QUIC amplification attacks).
So what you want is "I, H" in the TLS handshake, modern clients to know G,
and 'legacy' clients to know how to get "G" and "D" as needed. AIA is the
best way to do that, and the most interoperable way, without requiring
