I agree that the problem would still remain on a global scope, but the argument, that there are other "dirty" CA's so we have to be "dirty" too, is very questionable... at least...
Is this a race to the bottom: The CA with lowest security standards wins? Why should one trust any of those? > On 15 Dec 2015, at 03:32, Noah Kantrowitz <[email protected]> wrote: > > And the counter to that is the huge number of existing CAs that allow > URL-based verification. We would pay the costs of increased complexity for > setup (for example, the existing LE client would be totally impossible) but > don't actually reap any benefits until the last of those CA shuts down. > Hence, pragmatism with a bias towards improving accessibility. If the person > running your website is actively hostile, they can probably get into some > pretty serious mischief anyway :-/ (all of my arguments are absolutely > dismissible as "slippery slope" fallacies for those playing along at home) > > --Noah > >> On Dec 14, 2015, at 6:20 PM, Julian Dropmann <[email protected]> wrote: >> >> 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 <[email protected]> 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 <[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 >>> >>> _______________________________________________ >>> 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
