On Friday, March 8, 2019 at 2:35:42 PM UTC-8, Ryan Sleevi wrote:
> On Fri, Mar 8, 2019 at 4:35 PM watson--- via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>
> Is there a security considerations or analysis that explores the
> considerations that were examined with respect to these certificates?
First let me thank you for your thoughtful and detailed reply.
I think this indicates that we should expand the security considerations
section of the draft. Certainly I've mostly been thinking in terms of ensuring
cross-protocol attacks and the like are prevented more than broader WebPKI
policy questions.
>
> 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.
>
> One example that stands out is the requirement that the extension MUST be
> marked non-critical. The rationale for that decision would be useful to
> capture in some way, whether in this document or in a supplementary
> "explainer", so as to capture the thinking. A small note, if it can be
> accepted, is that I believe the intended wording is "MUST NOT be marked
> critical", since as a DEFAULT value in a sequence with a value of FALSE,
> you would not encode anything for the criticality field. I highlight this,
> as it's an area where CAs have incorrectly DER encoded FALSE values (see
> https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix
> ), and such wording may lead to a similar, and undesirable, result.
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.
>
> If using delegated credentials on a webserver with a separate server
> > producing the delegated credentials, an event like Heartbleed that results
> > in disclosure of a key has a more limited impact than the disclosure of the
> > certificate's private key. Cloudflare has implemented Keyless SSL to
> > achieve a similar effect, and this draft came out of the TLS WG's
> > recognition that a standardized technology with similar properties would be
> > broadly desirable. We need certificates to opt-in due to concerns about
> > cross-protocol attacks. Delegated credentials can only be used with one
> > signature scheme and are tied to the certificate and scheme used to issue
> > them, so are robust in the face of cross-protocol attacks. To further
> > minimize the risk we will add to security considerations that ECDSA certs
> > are better due to Bleichenbacher issues in old TLS versions.
> >
>
> To confirm: In the event of a Heartbleed-like event, the expectation would
> be that CAs would revoke non-Delegation Credential certificates (due to the
> possible key compromise issues), but that certificates bearing the
> delegationUsage extension would not be revoked, correct?
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.
>
>
> > We are currently interested in deploying delegated credentials over the
> > next few months, and hope CAs will help enable this for the broader web
> > ecosystem. Nothing in the BR or Mozilla Root Program requirements forbids
> > issuing certs with these extensions, but we felt it would be prudent to ask
> > for feedback on this proposal from more sources then just those involved in
