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

[Michael Wyraz <[e-mail]>]

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 <[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