I think the problem here is not that its too complex stuff, the real problem is that you are not currently able to automate it in the real world.
I understand the reasoning that you subordinate every other goal, even security to this in order to reinforce the usage of TLS in general. But there is a difference, if some random CA offers a proprietary verification mechanism doing this, then when there is a public standard not covering those issues. There should at least be an optional way for implementations which shows how it should be done in a more optimistic scenario, then the current one where, as you mentioned earlier "CAs only have p#10 in common". The same thing applies to domain registrars I guess. On Tue, Dec 15, 2015 at 2:43 PM, Stephen Farrell <[email protected]> wrote: > > Hiya, > > On 15/12/15 13:02, Michael Wyraz wrote: > > 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. > > Yes, I understand that and didn't actually refer to LE at all in > my mail. > > > So shouldn't we > > think/discuss what comes after "now"? > > Basically, IMO only after we first get a "now" that works. I've seen > over-complex PKI management efforts fail for 20 years. Another such > failure isn't interesting. > > > 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. > > I like ideas that are additional to the easiest HTTP stuff. But that > easiest stuff is the core work here. But sure, additional things that > are optional are fine. > > Personally the optional thing in which I'm much more interested is > a simple put-challenge-in-DNS one where the CA pays attention to > DNSSEC, since that's the use-case I have and that would provide > some better assurance to the certs acquired via acme. I can see > that there might also be value for some (other) folks in SRV if > it means no need to dynamically change DNS. > > But, if someone is saying "we must all do these more complex things > for security reasons" then they are, in this context, wrong. And > my mail was reacting to just such a statement. > > > > > 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. > > Ease of deployment wins IMO. I think an SRV based solution will be > a niche and ought not be used by the default/basic mechanism. > > S. > > > > > > 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 > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
