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

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/12/15 14:11, Julian Dropmann wrote:
> 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.

Not sure I agree but I'm pretty sure it's moot:-)

> 
> I understand the reasoning that you subordinate every other goal, even
> security to this in order to reinforce the usage of TLS in general.

To "subordinate security" with no qualification is not what we're
discussing. We're discussing whether acme's baseline must be better
than what the current WebPKI provides to browsers. My take is that
if a proposal to be more secure can damage automation or the chances
of deployment, then that proposal is one to push back against.

If we can get this automation out there and being used, then we can
and I think will improve it over time.

No matter how many good (or bad) ideas are described in CMP, those
cannot be improved upon as CMP is not deployed. (Except in some tiny
wee corners of the Internet, last I looked.)

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

We have many public standards for PKI management that are either just
not implemented, or not deployed or, at best, partially deployed in
ways that don't get useful interop with end entities. That leads to
both more use of cleartext protocols and to silly outages and errors.
Those are the differences about which I care more here.

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

As I said before, I think options are fine but need to not distract
from getting the initial work done and deployed. For me, that initial
work is basically: have "apt-get install apache2" install a cert that
works in most browsers so web sites default to HTTPS from day zero.
(Yes, I know the wg's goals are not precisely that, but it's v. close.)

Arguments that acme must do X because X is better need to be
carefully evaluated in that light.

Cheers,
S.

PS: In case it's not clear, all the above is without any IETF hat, just
as a consumer of the acme protocol and as someone who's wasted too
much of my working life on failing to solve this particular problem;-(

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