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