On Thu, Dec 5, 2019 at 10:42 AM Nick Lamb <n...@tlrmx.org> wrote: > On Wed, 4 Dec 2019 17:12:50 -0500 > Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> 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 out-of-band predistribution (to *legacy* clients) about G and D. I don't disagree on the privacy concerns with AIA, but I think folks are overlooking the tradeoffs, complexity, or the fact that today we afford CAs much greater flexibility than is perhaps desirable in the structure of their PKIs. Intermediate preloading *is* valuable, but it does have limitations, and those limitations have consequences to the agility of the ecosystem. That's not a problem if a client is going like Firefox, from nothing to preloading, but it's much more complex and nuanced if a client is going from AIA to preloading, because that's a step to less agility. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy