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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>>> >>>>> 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 >>>>>> >>>>>> >>>>>> >>>>>> [email protected] >>>>>> https://www.ietf.org/mailman/listinfo/acme >>>>> _______________________________________________ >>>>> Acme mailing list >>>>> >>>>> >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/acme >>>> >>>> _______________________________________________ >>>> Acme mailing list >>>> >>>> >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/acme >>> _______________________________________________ >>> Acme mailing list >>> >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/acme >> >> >> _______________________________________________ >> Acme mailing list >> >> [email protected] >> https://www.ietf.org/mailman/listinfo/acme > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
