Re: [Acme] kinds of proof

[Viktor Dukhovni <[e-mail]>]

On Fri, Nov 28, 2014 at 10:37:01AM -0800, Paul Hoffman wrote:

> >  * Does the web server have to be on port 443 with TLS enabled
> >    (perhaps with a temporary self-signed certificate)?  Or is it
> >    sufficient to control port 80 or some other port with or without
> >    TLS?
> > 
> >  * If on port 443, is an existing certificate from any of the
> >    usual public CAs (other than LE) (if also usable as a TLS client
> >    cert to authenticate to the provisioning system) accepted as
> >    evidence of authenticity for bootstrapping trust with LE?
> 
> Why should ability to control port 80 or 443 be a determinant
> for proving control of "web server" at "domain name"? Not all web
> service is run on port 80, and not all secure web service is run
> on port 443. A CA can validate that the requestor can control some
> HTTP service on some port at the domain name. If a CA has a policy
> that is more restrictive than that, ACME can trivially support that
> policy with more error codes.

Because unfortunately, Web PKI certificates are host-wide, they don't
specify a port.  Anyone who can run some program on a machine can
bind to some random port and start a web service.  Possibly port-forwarded
somewhere else via SSH!

It is far from clear to me that every "shell" user of a machine
should be authorized to obtain certificates for the whole machine.

> >  * If the domain is DNSSEC signed, is it reasonable (I hope)
> >    to raise the bar, and require proof of DNS control?  Since
> >    bootstrapping with just web server control and no existing
> >    credentials is vulnerable to MiTM, and signed domains are
> >    making an effort to harden against such attacks?
> 
> I disagree that ACME-the-protocol should raise the bar past what
> we use for domain verification today. It's fine if a CA who uses
> ACME does.

The protocol is just a syntax, and indeed I asking a question about
appropriate CA policy.  Perhaps some guidance to CAs implementing
the protocol would not be amiss.

As for not raising the bar, "today" there is essentially no DNSSEC
deployment (just under 1% of domains in the Alexa top 1,000,000).

So this is not "raising the bar" for any established scenarios,
rather asking whether we should maintain the bar at the same woefully
insecure level, even when DNS is beginning to provide greater
security.

At the very least I would expect the CAs resolver that validates
control over DNS to have DNSSEC validation turned on to drop "bogus"
replies.  However, I would also advocate that web server control
boostrapping over much weaker channels should not bypass stronger
DNS security (the domain owner has signalled the capability to
authenticate control of the domain, and we should not allow downgrade
attacks).

-- 
	Viktor.