Re: [Acme] Issuing certificates based on Simple HTTP challenges

[Julian Dropmann <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]>
> >>>> 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
> >>>>> <[e-mail]> 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 <[e-mail]>
> >>>>>> 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 <[e-mail]>
> >>>>>>> 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
> >>>>>>>>> <[e-mail]> 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
> >>>>>>>>>>> <[e-mail]>
> >>>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> [e-mail]
> >>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/acme
> >>>>>>>>>>> _______________________________________________ Acme
> >>>>>>>>>>> mailing list
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> [e-mail]
> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/acme
> >>>>>>>>>> _______________________________________________ Acme
> >>>>>>>>>> mailing list
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> [e-mail]
> >>>>>>>>>> https://www.ietf.org/mailman/listinfo/acme
> >>>>>>>>> _______________________________________________ Acme
> >>>>>>>>> mailing list
> >>>>>>>>>
> >>>>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>>>>>>>
> >>>>>>>> _______________________________________________ Acme
> >>>>>>>> mailing list
> >>>>>>>>
> >>>>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>>>>>> _______________________________________________ Acme mailing
> >>>>>>> list [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/acme
> >>>>>> _______________________________________________ Acme mailing
> >>>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>>>> _______________________________________________ Acme mailing
> >>>>> list [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>>> _______________________________________________ Acme mailing list
> >>>> [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>> _______________________________________________ Acme mailing list
> >>> [e-mail] https://www.ietf.org/mailman/listinfo/acme
> >>>
> >> _______________________________________________
> >> Acme mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/acme
> >
> >
> > _______________________________________________
> > Acme mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> >
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>