Stephen, I agree that getting things started I very important for lets encrypt. But in my understanding, this is the mailing list for discussing the ACME protocol, not the 1st implementation of it. So shouldn't we think/discuss what comes after "now"?
IMO using SRV as an option for specifying which host/port (if any) is responsible for ACME is a step in the right direction. It can be optional which gives security-aware admins the possibility to make their system more safe without loosing comfort for those who don't care a lot about security. Have a look at all the discussions about "allow other ports than 80/443". People argue what could be safe ports for ACME and what not. Why do an assumption instead of let people declare the port with a fallback to 80/443. Regards, Michael. > > On 15/12/15 03:03, Julian Dropmann wrote: >> 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? > I think you are not taking into account what I think is the > point of acme. The overwhelming goals here are automation and > real (*) deployment of a standards based way to manage PKI > for the most popular applications using PKI. > > Once we get the above done, then the security/assurance bar > can be raised over time in a useful manner. Today, it cannot, > as the CAs only have p#10 in common really and the rest of > what they do is effectively proprietary. > > So it is entirely valid here to argue that "same security as > current WebPKI" is a good starting point. > > Cheers, > S. > > (*) I say that as a co-author of RFC2510 and successors which > was afaik the original but by no meanss the only failed attempt > to do this. My experience with all of that tells ms that it is > more important to prioritise initial deployment over almost all > else. > > >>> 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 >> > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
