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