That's a fair point.  Although note that critical extension bugs don't tend
to be
of the "ignore critical extension" variety (though that happens), they tend
to be 
of the "understand the critical extension for the purposes of rejecting it
and then 
getting the logic backwards" or something similar.

The self-signedness is probably the most important mitigating factor ... we
might
want to make sure that the draft has enough requirements to make sure that
the margin of error is two to three software bugs in all compliant
implementations, 
and is never just one.

-Tim

> -----Original Message-----
> From: Jacob Hoffman-Andrews [mailto:j...@eff.org]
> Sent: Monday, March 5, 2018 5:42 PM
> To: Tim Hollebeek <tim.holleb...@digicert.com>; acme@ietf.org
> Subject: Re: [Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt
> 
> On 03/05/2018 04:37 PM, Tim Hollebeek wrote:
> > I think we may come to regret using that trick so much.  Such schemes
> > are only one software bug away from having rather profound effects on
> > trust decisions and the entire ecosystem.
> This is a good point, but an important mitigating factor is that these are
self-
> signed certificates, as compared to CT's precertificates, which are signed
by a
> trusted issuer but poisoned. And they are only presented when the acme/1
> ALPN is negotiated. So you'd need three software bugs, each of which would
be
> a game-over bug on its own:
> 
>  - ignoring a critical extension
>  - trusting a self-signed certificate
>  - sending acme/1 ALPN for non-validation traffic

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Reply via email to