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

[Julian Dropmann <[e-mail]>]

The important difference is, that only zones which intent to use ACRE would create such an SRV record in the first place.
With the current design any A record host in the world can obtain certs. By using an ACRE specific SRV record the domain owner at has at least shown the intent to use ACRE for his zone. And also he could limit it to a specific port number/service on that host.
I think this would be a very huge security improvement, and of the verification quality in general, but only if this would not be an optional thing.

> On 15 Dec 2015, at 00:02, Noah Kantrowitz <[e-mail]> wrote:
> 
> It wouldn't matter anyway because even with a SRV delegation for the challenge, the final cert is still issued against only a hostname, not a specific service. Combined with the fact that there are existing CAs that do a rough equivalent of http-01 and we can't expect that to go away any time soon, it isn't hard to see why pragmatism won out in the initial design. Fixing this for reals requires TLS-level protocol improvements for per-service certificates. Not against that, just saying you've got a long road ahead of you.
> 
> --Noah
> 
>> On Dec 14, 2015, at 2:47 PM, Michael Wyraz <[e-mail]> wrote:
>> 
>> I thought about all the DNS stuff and came to the conclusion that focussing ssl certs for https only and ignoring all the rest may cause further security issues.
>> E.g. if I delegate http (via A-record or CNAME) to someone else, he can now create valid ssl certs for my mail server which I did not delegate. IMO A-record should be dedicated to http(s) (for legacy reasons, see http://stackoverflow.com/questions/9063378/why-do-browsers-not-use-srv-records) and all other services (inclusing ACME) should use their own srv records.
>> 
>> Looks like a decision between comfort and security - let's bet what will win...
>> 
>>> Fair, adding a DNS-level opt-out would be a reasonable addition for future iterations, but not a hugely pressing issue given the expected use cases.
>>> 
>>> --Noah
>>> 
>>> 
>>>> On Dec 14, 2015, at 12:55 PM, Michael Wyraz <[e-mail]>
>>>> wrote:
>>>> 
>>>> So just leave out the part with "then switch completely from A to SRV" and allow both. This gives people the comfort to use A/CNAME stuff while others who prefer security use SRV. Both are happy, problem solved ;-)
>>>> 
>>>>> Using normal A/CNAME records matches the default use case of HTTPS a lot more smoothly and allows a lot of cool transparent upgrade stuffs from folks like DreamHost or Fastly that already do the CNAME setup as part of user on-boarding and can run http-01 on the behalf of the user to set them up on an SNI termination. If all the major CDNs did this, it would be worth the negative issues where HTTP is delegated to an untrusted service. If TLS ever grows per-service restrictions that would be appropriate here, but that is waaaay out of scope for ACME I would think :-/
>>>>> 
>>>>> --Noah
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Dec 14, 2015, at 11:17 AM, Michael Wyraz <[e-mail]>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> Julian,
>>>>>> 
>>>>>> the issue your described here is caused by the assumption that any the A-record points to a host that should be allowed to create certs for that domain. IMO a solution would be simple: use some special SRV record that points to a service that does the challenge. Allow users to set this record to something like "none" to completely disallow ACME-based cert generation. Use A-record as fallback for a given time (e.g. one year), then switch completely from A to SRV,
>>>>>> 
>>>>>> Problem solved ;-)
>>>>>> 
>>>>>> And it's almost as comfortable as using the A-record because it needs just one single additional step, no change of the client, absolutely minimal change to the server, no extra software or support for dynamic DNS updates or such.
>>>>>> 
>>>>>> As a side effect it solves many problems with ACME in complex environments like geo-distributed dns.
>>>>>> 
>>>>>> Kind regards,
>>>>>> Michael.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Hello,
>>>>>>> 
>>>>>>> maybe I am just a naive concerned user, but in my opinion there is one major issue with the Simple HTTP challenge and possibly other challenges, specified by ACME:
>>>>>>> 
>>>>>>> Any host which is specified by an A/AAAA record of that domain zone can obtain trusted certificates in the name of the domain zone owner.
>>>>>>> Lets assume I host an private XMPP server using TLS on my own domain using an SRV record, and I point an A record to a third party hoster which hosts my public web blog.
>>>>>>> Now this third party hoster would be able to obtain signed certificates for my domain using ACME and use that to host an XMPP service on that domain using the standard port.
>>>>>>> Clients which trust that CA are now perfectly happy connecting to that entity.
>>>>>>> 
>>>>>>> By creating an A record I ofcourse need to trust that host to some degree, but I still would expect the CA to verify if the requester has control over the DNS zone itself an not just over a single service running there.
>>>>>>> 
>>>>>>> And consequently if it is valid to verify over HTTP, then maybe another CA validates the domain ownership by a mail service/MX record, and a third one over XMPP/SRV.
>>>>>>> 
>>>>>>> This effectively means, as a domain zone admin, I have to trust every single service I define, not just to properly deliver this service, but also not to exploit his ability to obtain signed certificates in my name.
>>>>>>> 
>>>>>>> Also you rely on the fact that on UNIX only root can bind on port 80 and 443. Lets assume there is an OS out there which does not enforce this restriciton,
>>>>>>> now any user on that host is able to obtain signed certificates for that domain.
>>>>>>> 
>>>>>>> Maybe I missed something here, but overall this seems to be a very bad idea to automatically issue certificates without requiring a change in the actual DNS zone the certificate is issued for.
>>>>>>> 
>>>>>>> Kind regards,
>>>>>>> Julian Dropmann
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> Acme mailing list
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>>> _______________________________________________
>>>>>> Acme mailing list
>>>>>> 
>>>>>> 
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/acme
>>>>> 
>>>>> _______________________________________________
>>>>> Acme mailing list
>>>>> 
>>>>> 
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/acme
>>>> _______________________________________________
>>>> Acme mailing list
>>>> 
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>> 
>>> 
>>> _______________________________________________
>>> Acme mailing list
>>> 
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>> 
>> _______________________________________________
>> Acme mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme