Re: Requirements for Secondary Certificates (#522)

On Tue, Apr 10, 2018 at 2:42 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> > One proposal is to define a new OID and require it to be on any
> > certificates that servers present as Secondary.  This poses
> > substantial deployment problems.
>
> Yeah, that is going to have deployment problems.
>

I'd like to understand more about these deployment problems. It seems these
are based on assumption of long-lived certificates and the difficulty of
obtaining new certificates. However, a number of CDNs and large providers
are using automated APIs for their issuance and renewal, and a number of
CAs offer automated APIs for end-users, including, notably, Let's Encrypt.

I can understand that this might have been true a decade ago, but it seems
reasonable to challenge the claim now as to difficulty - at least for those
providers that aren't BYOC.

Similarly, the concerns around appearances - the 'compromise me' flag - is
one way of framing the discussion, but isn't this fundamentally the
security tradeoff being discussed? That is, that unless servers take
meaningful steps and are aware of the risks, this weakens the security
assurances that servers have by default - and that clients and networks
implicitly rely on (or, in the case of things like DNS-over-HTTPS and
BGPSec, explicitly rely on)


> > Another idea is to require the thing presented by the server to be,
> > not a certificate, but a delegated credential (see
> draft-ietf-tls-subcerts).
> > However, that has very similar concerns since subcerts requires the
> > certificate to explicitly opt in to Delegated Credentials.  That is
> > a more general capability that people are likely to adopt more willingly.
> > The key compromise threat model looks almost exactly the same, though,
> since
> > once the key is compromised you can mint a delegated credential.  (And
> > there’s also the fact that it’s a -00 draft that probably has a lot more
> > runway before it lands in browsers.)


While I agree that it looks similar, there is a meaningful difference in
the ideal deployment - namely, in a Delegated Credentials model, you can
keep your DC signing key offline or in a higher protected (possibly
airgapped or HSM protected) network, while your delegated credential key is
short-lived and distributed. Now, in practice, if you reuse the key in a DC
model, then the concerns are similar - and if you don't take steps to
separate out the key protection lifecycle, the concerns are similar. Thus,
to a client, the security assurances are similar - but to a server, there
are steps they can take in DC that they cannot take with a Secondary
Certificate (due to the effective online-signing requirement)

It's worth noting that in addition to the similarities between Secondary
Certificates and Delegated Credentials (in terms of oracles and
compromise), there are also similarities to Signed HTTP Exchanges (
https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html
) - in that potentially third-party domains can assert (by providing a
signed exchange) control over a domain.