DVSNI has the same protection level than cleartext tokens (or challenge emails). It is an opportunistic way of automatically verifying the domain. I dont think the TLS part in there is meant to add any protection (how should it, if the cert is not trusted).
Besides scanning from different locations to reduce the risk and of course not using the method when the idendity is already protected with a key there is not much ACME can do in a automated CA scenario. This is pretty similiar to SSH's TOFU. Having said that I was quite suprised that a new method was suggested. It IMHO mainly adds bloat. Gruss Bernd Am Wed, 25 Mar 2015 17:15:27 -0500 schrieb Joseph Lorenzo Hall <[email protected]>: > On Wed, Mar 25, 2015 at 2:42 PM, John Mattsson > <[email protected]> wrote: > > > > > > On 25 Mar 2015, at 13:24, Jonathan Rudenberg > > <[email protected]> wrote: > > > > > > On Mar 25, 2015, at 9:35 AM, John Mattsson > > <[email protected]> wrote: > > > > Hi, > > > > Some high level comments on draft-barnes-acme (the GitHub version) > > > > > > - Security: > > The security of this seems to need some serious rethinking. The > > “Domain Validation with Server Name Indication” challenge seems > > totally nonsecure, allowing ANY on-path attacker to get > > certificates issued. I think this challenge is unacceptable for > > certificate issuance and I think it should be removed. Just because > > I let Amazon, Microsoft, Google or any other cloud provider run my > > web server does not mean I give them the right to request > > certificates for my domain. > > > > > > Thanks for pointing this out. > > This seems like a big deal, no? That is, since SNI is one of the few > things not protected in the TLS handshake, it does seem spoofable. If > there's not something I'm missing, it seems like the proposal should > just drop DVSNI altogether. > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
