Re: [Acme] Issuing certificates based on Simple HTTP challenges

[Julian Dropmann <[e-mail]>]

> On 15 Dec 2015, at 20:41, Noah Kantrowitz <[e-mail]> wrote:
> 
> 
>> On Dec 15, 2015, at 9:48 AM, Phillip Hallam-Baker <[e-mail]> wrote:
>> 
>> 
>> 
>>> On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <[e-mail]> wrote:
>>> 
>>> On Dec 15, 2015, at 7:17 AM, Michael Wyraz <[e-mail]> wrote:
>>> 
>>> Stephen,
>>>> Yes, I understand that and didn't actually refer to LE at all in my mail.
>>> I'm sorry if I missunderstood you with that.
>>> 
>>>> Basically, IMO only after we first get a "now" that works
>>> We have a working HTTP-01 spec, implementation and CA. What's missing
>>> for "a 'now' that works"?
>>> 
>>>> Personally the optional thing in which I'm much more interested is a
>>>> simple put-challenge-in-DNS one where the CA pays attention to DNSSEC,
>>>> since that's the use-case I have and that would provide some better
>>>> assurance to the certs acquired via acme. I can see that there might
>>>> also be value for some (other) folks in SRV if it means no need to
>>>> dynamically change DNS. But, if someone is saying "we must all do
>>>> these more complex things for security reasons" then they are, in this
>>>> context, wrong. And my mail was reacting to just such a statement.
>>> Why not just placing a static public key to DNS that is allowed to sign
>>> ACME requests for this domain? Simple, no need for dynamic updates (yes,
>>> it's standardized for years but AFAIK not seen very often in real world
>>> scenarios).
>> 
>> Anything that makes deployment _harder_ than the current LE client is a move in the wrong direction. UX matters, with security more than just about anything else. Unless you can propose a user flow to go with this change, no amount of hypothetical correctness is worth having a tool no one will use.
>> 
>> Harder for whom?
>> 
>> The current scheme isn't going to work for any geolocation based systems and is a terrible fit for enterprise.
> 
> I think this is a bit of a red herring on a few fronts. You can use http-01 or similar strategies on a widely-replicated system, it is just annoying because you need to push the challenge response file to a bunch of places. If the geo-distributed piece is a CDN, the system is already designed to smash caches effectively so that is handled. Still, that is gross and a lot of work, but fortunately there is already a DNS challenge in the works that will help for some cases. It requires centralized command and control systems to use effectively, but that matches the structure of a lot of these big, distributed setups. The case we haven't covered is where you have a complex distributed setup but want to run the challenge on the edges. I question how many people want to do that but I agree it is non-zero and an http-srv-01 challenge type would help cover that (or fold it in to http-02 as an optional thing). The objection from myself and some others is the suggestion that we mandate DNS changes to use http-01 or tls-sni-01 because of the risk of a rogue HTTP server validating certs unexpectedly. Making that level of interaction with DNS required is a major UX change and will drastically reduce the number of people that will use LE and similar services.
> 
> --Noah

The target users are server admins right?
In order to set up their services, they should be familiar with DNS.
To use the current mechanism they already need to configure the A record. So whats the big difference? Instead of an A record they need to use an SRV record. So technically only the record type changes. Nothing else. How is that even a higher level of interaction?

There are other services requiring admins to create DNS records (Google Apps for example). They are being used.