(Sending from the right e-mail this time) Thanks for the responses! I think this is a great thing to bring here, because there are some interplays with policy and implications that can affect the design, as I discuss below. I'm trying to be mindful of proffering solutions outside of the TLS-WG, so mostly, I'm trying to provide context and framing and create some supporting paper trail. Totally happy to engage in the TLS-WG if there are substantive technical changes to address the specific policy concerns.
On Fri, Mar 8, 2019 at 7:16 PM watson--- via dev-security-policy < > [email protected]> wrote: > > I ask, because in the context of HTTP Signed Exchanges > > > https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html > > , > > there was an effort to introduce additional validation requirements, most > > notably, the explicit consent and opt-in by a site (via CAA) and a policy > > expectation encoded in the spec that CAs SHALL NOT issue unless that CAA > > constraint is satisfied. While in the case of HTTP Signed Exchanges, > these > > represent an extension of capability, and especially the ability to be > used > > in the absence of a direct connection to the authoritative origin (as > > determined by DNS), it would be useful to know what sort of > considerations > > have been made - whether it's ruling out particular concerns or including > > particular concerns (e.g. the inclusion within Section 3.2 of the draft > of > > the delegationUsage extension) > Are there specific concerns that you think should be addressed? Note that > any substantive discussions of changes beyond the editorial should take > place on the TLS-WG list. I was trying to capture a request to understand what the thinking had been. The design shape tends to evolve over time, and various considerations may be raised and ruled out, or result in design changes. Typically in the IETF drafts, the "Security Considerations" tend to focus on "Here's the concerns with the document in the current state", but I suppose I was trying to understand if there is more documentation on "Here were the concerns that motivated this particular decision", if there were any. It may very well be that various decisions were made by throwing darts at a dart board ;) The discussion of validation requirements naturally lead to a desire to understand more of the reasoning about how the conclusion was reached, not necessarily a disagreement with the conclusion. HTTP Signed Exchanges took a similar approach, but reached different conclusions. Those conclusions may have been (and likely are) due to their very different threat models, but understanding whether all this had been discussed and bashed out and reasoned about it just as useful as understanding the conclusion (i.e. that no additional validation is required), since that's what gives CAs and the community confidence that it's a sensible conclusion. I don't think these are things that necessarily need to be addressed in the draft; in many ways, they're answers to the policy questions that the technical draft raises. <snip> > Excellent editorial note! As for why not mark critical we want these > certificates to also work > for clients that do not support the extension. I can imagine a situation > where a certificate is on a low-performance HSM, and delegated credentials > are usually used, but then there is the occasional fallback. <snip> > The expectation is that certificates bearing the delegatedUsage extension > would not need to be revoked as they would not have been compromised. This > of course depends on the details: if a webserver was happily serving up the > entire disk, private keys included that otherwise were living in a > different process, then the certificates would be compromised and hence > need to be revoked. I think these two things may be incompatible. Given that it's not a critical extension, and thus MAY be used to terminate the connections, from a policy perspective, CAs would likely need to assume the key "probably" is compromised, and thus revoke. This means it doesn't really address the Heartbleed scenario - the certificates still end up revoked. Making the extension critical provides a greater signal to CAs that it's unlikely to have been used on the server (since conforming clients would have rejected it), and thus make it less likely to need to revoke the extension-bearing certificates vs the 'traditional' certificates. Not to pick on Cloudflare, but since they ran into a large revocation event re: Heartbleed, it actually makes a great example. If Cloudflare had been using delegated credential-enabled certificates for both DC-enabled and non-DC-enabled clients, then the safest path a CA could take to defend themselves against an adverse interpretation of the BRs or Mozilla Policy would be to revoke these certificates. If such certificates were unusable for non-DC-enabled clients, then there's stronger protocol-level indicators that such certificates would not have had their private keys exposed (only the DC keys would have been exposed), and thus it wouldn't be necessary to revoke the DC-enabled-certificates. Hopefully that makes sense; there's some interplay here between the policy implications and expectations of revocation, particularly around Heartbleed-like events, and what DC is trying to achieve. While DC (and things like keyless SSL) MIGHT mean the certificates and keys were less likely to be exposed for a given Subscriber/certificate, the conservative CA would take the conservative approach of assuming they had been, and require a key rotation regardless. <snip> > I do not understand what 7.1.2.4(b) is saying as applied to this matter. > What assertion is being made about what with this OID in place? I think > what you are saying is this OID should be opt-in on the part of the > Applicant and the BRs require it to be opt-in, and the security analysis > might be assuming this. The thinking here is this: Reading the BRs in a very conservative perspective, CAs need to be very careful about what additional extensions they include within a certificate, both as a matter of policy and as it matters to compliance with the BRs. A CA including an extension not enumerated in the BRs bears the burden of proof to demonstrate why the inclusion is permissible by the BRs. 7.1.2.4 places restrictions on the types of extensions, and thus the CA has to demonstrate that both conditions have been satisfied, even under a maximally pessimistic interpretation. Given this framing, my hope was to get a clear interpretation on the record for why it would be OK for CAs to include such an extension, and how they could demonstrate both criteria have been satisfied, even under a pessimistic reading. By discussing it here on m.d.s.p., that then makes it easier for CAs to point back to the public discussion and the interpretation that was discussed and the consensus reached, and thus allows a CA to respond to anyone that might file an incident report claiming non-compliance with the BRs (due to including the extension) with that discussion. Having that discussion now makes it easier for CAs wanting to adopt these certificates to have confidence that including it is defensible. :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
