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

From: Julian Dropmann <[email-masked]>
Date: Mon, 14 Dec 2015 17:24:15 +0100

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Dec 2015 16:38:16 +0000

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

Yes.

>Also you rely on the fact that on UNIX only root can bind on port 80 and 443.

Not for *security* but for connectivity.  That is an important difference.

---

From: Julian Dropmann <[email-masked]>
Date: Mon, 14 Dec 2015 17:53:17 +0100

> also not to exploit his ability to obtain signed certificates in my name.

And you are perfectly aware, that this was not the case before ACME-enabled
CAs existed, and now applies to every single domain admin on this planet,
right?

> 443.

If it was not for security, then why not allow other ports, so you can
verify the ownership while for example an application server is bound to
that port? The A record does not specify the port anyway.

---

From: moparisthebest <[email-masked]>
Date: Mon, 14 Dec 2015 11:58:06 -0500

On 12/14/2015 11:53 AM, Julian Dropmann wrote:
> And you are perfectly aware, that this was not the case before
> ACME-enabled CAs existed, and now applies to every single domain admin
> on this planet, right?

It always applied before as well.  In your example, your malicious blog
hoster could have just hosted un-encrypted xmpp on the default port as
well and xmpp clients that don't support SRV (which probably don't
exist? it's in the original RFC) would just happily connect there as
well, right?

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Dec 2015 19:00:35 +0200

> CAs existed, and now applies to every single domain admin on this planet,

I think there are non-ACME CAs that allow validation mechanism similar to
the HTTP validation (and where already before ACME ones came really
around).

-Ilari

---

From: Julian Dropmann <[email-masked]>
Date: Mon, 14 Dec 2015 18:03:55 +0100

On Mon, Dec 14, 2015 at 5:58 PM, moparisthebest <[email-masked]>
wrote:

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

Sure, they were able to provide malicious services under that domain, but
not with a valid certificate.
I think this is still a major difference.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Dec 2015 17:05:09 +0000

> And you are perfectly aware, that this was not the case before ACME-enabled CAs existed, and now applies to every single domain admin on this planet, right?

This absolutely was the case.  Other CA's have had http/https-based service.  Many do email-based confirmation, which requires that nobody run a "rogue" email server, for example.  Others have just replied with similar cases.

The DNS owner must trust or ensure that the hosts he/she is putting into the DNS data are behaving properly, for *their own definition of properly.*  This was always the case.  Likewise, the host owner must trust or ensure that all services on the host are similarly well-behaved, for their own definition of behavior.  This was always the case.

> If it was not for security, then why not allow other ports, so you can verify the ownership while for example an application server is bound to that port? The A record does not specify the port anyway.

As you say, the record does not specify the port.  The certificate is *for the host* So in essence, your last sentence answers your own question.

But alternative ports as being discussed on the mailing list here.  Have you been following it?

---

From: Julian Dropmann <[email-masked]>
Date: Mon, 14 Dec 2015 18:25:56 +0100

On Mon, Dec 14, 2015 at 6:05 PM, Salz, Rich <[email-masked]> wrote:

> ACME-enabled CAs existed, and now applies to every single domain admin on
> this planet, right?
>
> This absolutely was the case.  Other CA's have had http/https-based
> service.  Many do email-based confirmation, which requires that nobody run
> a "rogue" email server, for example.  Others have just replied with similar
> cases.
>
> The DNS owner must trust or ensure that the hosts he/she is putting into
> the DNS data are behaving properly, for *their own definition of
> properly.*  This was always the case.  Likewise, the host owner must trust
> or ensure that all services on the host are similarly well-behaved, for
> their own definition of behavior.  This was always the case.
>
> As you say, the record does not specify the port.  The certificate is *for
> the host* So in essence, your last sentence answers your own question.
>
I have not been following this list, until now this concern came up just
now.
I just concluded, the port limitation must be for security, because the
letsencrypt user guide makes so much effort to provide an alternative
webroot method in case you do not want to stop your existing server and the
"alternative port" solution seemed so obvious to me.

Anyway I kind of see your point and maybe you are right.
But I still want to throw in, that just because other CAs do it this way,
its not necessarily a good thing.

If there for example where a standard to make changes to you DNS
zone/nameserver, this would be a much better approach to verify domain
ownership automatically, so why not provide an automation for that first?
But of course I also see the practical approach here...

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 14 Dec 2015 19:44:07 +0200

> But of course I also see the practical approach here...

Like DNS UPDATE? Standardized in 1997...

IIRC, there have been patches to the reference ACME client (I don't
think those have gotten merged) that implement the client side of
DNS UPDATE.

It actually depends on usecase which of DNS or HTTP is more convinient.

-Ilari

---

From: Julian Dropmann <[email-masked]>
Date: Mon, 14 Dec 2015 19:34:16 +0100

> On 14 Dec 2015, at 18:44, Ilari Liusvaara <[email-masked]> wrote:
> 

If this standard exists, why do we not solely rely on that instead of introducing weaker mechanisms?

You already answered it: Because its more convenient.
You do not rely on name server providers to support that.

By providing those other methods, there is now even less incentive to implement/using it.

And by only having a single CA accepting the HTTP method you already have no security benefit anyway using it.

---

From: Michael Wyraz <[email-masked]>
Date: Mon, 14 Dec 2015 20:17:48 +0100

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.

> 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.
> 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.
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 14 Dec 2015 11:30:34 -0800

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

---

From: Michael Wyraz <[email-masked]>
Date: Mon, 14 Dec 2015 21:55:17 +0100

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 ;-)

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 14 Dec 2015 14:05:31 -0800

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-masked]> 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 ;-)

---

From: Michael Wyraz <[email-masked]>
Date: Mon, 14 Dec 2015 23:47:29 +0100

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

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 14 Dec 2015 15:02:33 -0800

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-masked]> 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...
> 
>>>>> On Dec 14, 2015, at 11:17 AM, Michael Wyraz <[email-masked]>
>>>>> 
>>>>>  wrote:
>>>>> 
>>>>> Julian,
>>>>>

---

From: Julian Dropmann <[email-masked]>
Date: Tue, 15 Dec 2015 03:20:36 +0100

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-masked]> wrote:
>

---

From: Noah Kantrowitz <[email-masked]>
Date: Mon, 14 Dec 2015 18:32:33 -0800

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-masked]> wrote:
>

---

From: Julian Dropmann <[email-masked]>
Date: Tue, 15 Dec 2015 04:03:45 +0100

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?

> On 15 Dec 2015, at 03:32, Noah Kantrowitz <[email-masked]> wrote:
>

---

From: Peter Bowen <[email-masked]>
Date: Mon, 14 Dec 2015 19:08:15 -0800

> the HTTP validation (and where already before ACME ones came really

Yes, many existing CAs offer validation via HTTP.

Comodo and Thawte/GeoTrust:
https://www.namecheap.com/support/knowledgebase/article.aspx/9637/68/how-can-i-complete-the-domain-control-validation-dcv-for-my-ssl-

GoDaddy:
https://www.godaddy.com/help/verifying-your-domain-ownership-for-ssl-certificate-requests-html-or-dns-7452

SpaceSSL (Certum):
https://spacessl.com/support/ (under Required documents)

ACME didn't invent validation via HTTP.

Thanks,
Peter

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2015 09:17:43 +0000

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

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.

>> 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
>> 
>>> 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.
>>> 
>>>> 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
>>>> 
>>>>> 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
>>>>>> 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
>>>>>> 
>>>>>> 
>>>>>>> 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
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 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
>>>>>>>>>> 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
>>>>>>>>>> Kind regards, Julian Dropmann
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> _______________________________________________ Acme
>>>>>>>>> mailing list
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> [email-masked] 
>>>>>>>> _______________________________________________ Acme
>>>>>>>> mailing list
>>>>>>>> 
>>>>>>>> 
>>>>>>>> [email-masked] 
>>>>>>> _______________________________________________ Acme
>>>>>>> mailing list
>>>>>>> 
>>>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________ Acme
>>>>>> mailing list
>>>>>> 
>>>>>> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>>>>> 
>>>>> _______________________________________________ Acme mailing
>>>>> list [email-masked] 
>>>> _______________________________________________ Acme mailing
>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/acme
>>> 
>>> _______________________________________________ Acme mailing
>>> list [email-masked] https://www.ietf.org/mailman/listinfo/acme
>> 
>> _______________________________________________ Acme mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/acme
> 
> _______________________________________________ Acme mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/acme
>

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 15 Dec 2015 14:02:32 +0100

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.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2015 13:13:04 +0000

> 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"?

I agree it is important to distinguish between LE and ACME.

But it is also important to realize that we are going for something that works in ACME-1, and that is acceptable to the Web PKI.  We have tried, many times, to make something that is totally correct and "better."  Certificates, right now, have no way to identify themselves as being limited to a specific TCP/IP port, be it IETF well-known or otherwise.  Therefore, attempts to constrain this protocol so that it can only be used to get certificates that way seems, ultimately, not worthwhile at this point.

If someone like the CABForum or a new IETF WG (PKIX-bis anyone?) defined an extension that said "this certificate is only used for HTTPS" then, an ACME-2 challenge that could get such certificates make sense.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2015 13:43:32 +0000

Hiya,

On 15/12/15 13:02, Michael Wyraz wrote:
> 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

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.

> their system more safe without loosing comfort for those who don't care

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.

> Why do an assumption instead of let people declare the port with a

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.

---

From: Julian Dropmann <[email-masked]>
Date: Tue, 15 Dec 2015 15:11:44 +0100

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.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2015 14:32:16 +0000

Hiya,

> the real problem is that you are not currently able to automate it in the

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

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

> verification mechanism doing this, then when there is a public standard not

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.

> 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;-(

---

From: Kim Alvefur <[email-masked]>
Date: Tue, 15 Dec 2015 15:37:41 +0100

> If someone like the CABForum or a new IETF WG (PKIX-bis anyone?) defined an extension that said "this certificate is only used for HTTPS" then, an ACME-2 challenge that could get such certificates…

There's SRVName from https://tools.ietf.org/html/rfc4985 which in theory
already can be applied to https already.  SRVNames are used in the XMPP
world a lot, maybe other places as well.

As for using SRV records, if someone goes and puts _acme._tcp IN SRV
then they already demonstrate control of the domain.

-- 
Kim "Zash" Alvefur

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2015 14:39:26 +0000

> world a lot, maybe other places as well.

But you can't put a SRVName in a certificate SAN field, can you?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 09:55:14 -0500

> But you can't put a SRVName in a certificate SAN field, can you?

Actually you can. The SRV label is simply a DNS name. That is arguably the
only way that you can legitimately create service specific certs in the
WebPKI.

Port specific certificates are an abomination that must not happen. Well
Known Ports are not a viable discovery technique for modern services and
the idea that they can provide domain separation is utter nonsense. SRV
prefixed domain names do actually provide the necessary separation.

The only objection people would make to SRV is that they would have to
rewrite their application to use SRV for discovery. But I don't see that as
a legitimate concern when the alternative would be having to re-engineer
PKIX and the WebPKI which simply isn't going to happen.

Port numbers are a transport layer attribute and the WebPKI is an
application layer concern.

---

From: Kim Alvefur <[email-masked]>
Date: Tue, 15 Dec 2015 16:08:52 +0100

> only way that you can legitimately create service specific certs in the

Almost, but SRVname has its own OID, so it's not the same as a DNSName.
 But they live among the other SAN fields.

-- 
Kim "Zash" Alvefur

---

From: Michael Wyraz <[email-masked]>
Date: Tue, 15 Dec 2015 16:17:14 +0100

Stephen,
> Yes, I understand that and didn't actually refer to LE at all in my mail. 
I'm sorry if I missunderstood you with that.

> Basically, IMO only after we first get a "now" that works
We have a working HTTP-01 spec, implementation and CA. What's missing
for "a 'now' that works"?

> 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. 
Why not just placing a static public key to DNS that is allowed to sign
ACME requests for this domain? Simple, no need for dynamic updates (yes,
it's standardized for years but AFAIK not seen very often in real world
scenarios).

Regards,
Michael.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 10:46:55 -0500

>  But they live among the other SAN fields.

Its worth re-reading the RFC.

https://www.ietf.org/rfc/rfc4985.txt

The reason for introducing a separate OID seems to have been wanting to
drop the protocol component which simplifies things a lot for name
constraints.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Dec 2015 11:16:46 -0500

> the HTTP validation (and where already before ACME ones came really

https://buy.wosign.com/free

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Dec 2015 16:52:17 +0000

Hiya,

> for "a 'now' that works"?

PKI management with automation that gets deployed and that
provides interop between end entities and a range of CAs.
The core stuff acme is doing is the missing bit.

> it's standardized for years but AFAIK not seen very often in real world

Once one can modify DNS at all then that can be yet another optional
thing some folks might like I guess.

I don't know how this WG can choose between all these various options
in a meaningful manner tbh. I'm pretty sure that trying to do so now
wouldn't necessarily be a good plan. I'd be for waiting and seeing
how a few CAs running acme get on, and what real demands arise for more
than the basic approach that doesn't need to  modify DNS might be the
right idea. (Even if that's goes against my own wish to have the DNSSEC
based thing done soon.) But that's a question for the chairs and not
me.

S.

---

From: Noah Kantrowitz <[email-masked]>
Date: Tue, 15 Dec 2015 09:25:28 -0800

> On Dec 15, 2015, at 7:17 AM, Michael Wyraz <[email-masked]> wrote:
> 
> Stephen,

Anything that makes deployment _harder_ than the current LE client is a move in the wrong direction. UX matters, with security more than just about anything else. Unless you can propose a user flow to go with this change, no amount of hypothetical correctness is worth having a tool no one will use.

--Noah

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 12:48:36 -0500

On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <[email-masked]>
wrote:

> Anything that makes deployment _harder_ than the current LE client is a
> move in the wrong direction. UX matters, with security more than just about
> anything else. Unless you can propose a user flow to go with this change,
> no amount of hypothetical correctness is worth having a tool no one will
> use.
>

Harder for whom?

The current scheme isn't going to work for any geolocation based systems
and is a terrible fit for enterprise.

The workflow for using a LRA would be as follows:

1) Set up your ACME local RA on some host, e.g. lra.example.com

2) Generate a self signed cert for the LRA

3) Calculate the fingerprint of the KeyInfo blob (see
https://tools.ietf.org/html/draft-hallambaker-udf-00)

MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42

4) Create a CAA record with some tag:

example.com CAA acme 0 "lra.example.com
lra=MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42"

At this point, we have published all the necessary control information to
allow acme clients to automatically discover the LRA they are to connect to
for issue of certificates and the issuing CA has all the information needed
to authenticate the requests.

Note that in this particular case, the mechanism used to authenticate the
client to the LRA is out of scope of ACME because it is no longer a WebPKI
authentication, it is an internal configuration decision.

The simplest mechanism is probably for the acme client to generate a
keypair for that particular host and use that to authenticate host requests
to the LRA. The LRA would require some UI to authorize requests of course.

In a production environment, it might not be desirable to generate the
server keys on the servers that are actually going to use them.
Alternatively we might want to use the co-operative key generation
technique I demonstrated at CFRG in Prague.

If you are managing one server, a simple protocol is simplest. If you are
managing more than one then it probably is not. One of the main ways in
which PKIX became so complicated was that people tried to make it much
simpler than the problems required. So instead of one
revocation/status/validation mechanism we ended up with four incompatible
schemes.

The use of LRAs has been absolutely standard in enterprise PKI for 20
years. This is a feature we know is essential CAA was originally designed
to present all the information required to manage certificate issue.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2015 18:07:23 +0000

>The current scheme isn't going to work for any geolocation based systems and is a terrible fit for enterprise. 

The current scheme does work for geolocation based systems; Akamai does it.

I wouldn't say it's a terrible fit for enterprise.  Not ideal certainly, but that's okay.  Later on we can come up with more enterprise-friendly challenges if necessary.  Enterprises have, particularly lately, shown themselves quite willing to forego bespoke solutions over what everyone else on the Internet is doing. :)

---

From: Noah Kantrowitz <[email-masked]>
Date: Tue, 15 Dec 2015 11:41:08 -0800

> On Dec 15, 2015, at 9:48 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> 
> 
> On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <[email-masked]> wrote:
> 

I think this is a bit of a red herring on a few fronts. You can use http-01 or similar strategies on a widely-replicated system, it is just annoying because you need to push the challenge response file to a bunch of places. If the geo-distributed piece is a CDN, the system is already designed to smash caches effectively so that is handled. Still, that is gross and a lot of work, but fortunately there is already a DNS challenge in the works that will help for some cases. It requires centralized command and control systems to use effectively, but that matches the structure of a lot of these big, distributed setups. The case we haven't covered is where you have a complex distributed setup but want to run the challenge on the edges. I question how many people want to do that but I agree it is non-zero and an http-srv-01 challenge type would help cover that (or fold it in to http-02 as an optional thing). The objection from myself and some others is the suggestion that we mandate DNS changes to use http-01 or tls-sni-01 because of the risk of a rogue HTTP server validating certs unexpectedly. Making that level of interaction with DNS required is a major UX change and will drastically reduce the number of people that will use LE and similar services.

--Noah

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 16:17:02 -0500

On Tue, Dec 15, 2015 at 2:41 PM, Noah Kantrowitz <[email-masked]>
wrote:

> I think this is a bit of a red herring on a few fronts. You can use
> http-01 or similar strategies on a widely-replicated system, it is just
> annoying because you need to push the challenge response file to a bunch of
> places. If the geo-distributed piece is a CDN, the system is already
> designed to smash caches effectively so that is handled. Still, that is
> gross and a lot of work, but fortunately there is already a DNS challenge
> in the works that will help for some cases.
>

And is likely to be challenged by the IPR holder.

Keys in the DNS has prior art. It is also rather simpler to implement.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 15 Dec 2015 18:24:54 -0500

On Tue, Dec 15, 2015 at 4:17 PM, Phillip Hallam-Baker
<[email-masked]> wrote:
>> > anything else. Unless you can propose a user flow to go with this change, no
>> > amount of hypothetical correctness is worth having a tool no one will use.
>> >
>> > Harder for whom?
>> >
>> gross and a lot of work, but fortunately there is already a DNS challenge in
>> the works that will help for some cases.
>
>

You've mentioned IPR a couple of times.  If you have knowledge of IPR
in this space, disclosures would be very helpful.  Same goes for
anyone else here.

Thanks,
--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 18:45:10 -0500

Here is a handy list

https://cabforum.org/ipr-exclusion-notices/

On Tue, Dec 15, 2015 at 6:24 PM, Richard Barnes <[email-masked]> wrote:

> a

---

From: Julian Dropmann <[email-masked]>
Date: Wed, 16 Dec 2015 02:44:59 +0100

> On 15 Dec 2015, at 20:41, Noah Kantrowitz <[email-masked]> wrote:
> 
> 

The target users are server admins right?
In order to set up their services, they should be familiar with DNS.
To use the current mechanism they already need to configure the A record. So whats the big difference? Instead of an A record they need to use an SRV record. So technically only the record type changes. Nothing else. How is that even a higher level of interaction?

There are other services requiring admins to create DNS records (Google Apps for example). They are being used.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 02:26:30 +0000

Hiya,

On 16/12/15 01:44, Julian Dropmann wrote:
> The target users are server admins right? In order to set up their
> services, they should be familiar with DNS. 

Familiar with != has write access to.

In my university, I have root on 24U of boxen with zero write
access to the routers, f/w, DNS or mail servers, meaning that
for 13 years I couldn't get the two that are publicly visible
web servers certified by any CA any time I checked, which was
admittedly not that often.

ACME (via LE in that case, but I've no allegiance) fixed that
in a couple of minutes. And those minutes didn't require deep
knowledge of anything - relative ignorance would have worked
just as well, which is fantastic:-)

And before someone argues, sure there are other situations but
our goal here is to define a protocol that works in the most
common of those cases as easily as possible and that supports
automation.

> To use the current
> mechanism they already need to configure the A record. 

Not necessarily the same admins. That much is pretty obvious
and unless someone has demographics about how many sysadmins
have what access to what (which would be great!) I think this
is repetitive argument and therefore pointless.

Cheers,
S.

> So whats the
> big difference? Instead of an A record they need to use an SRV
> record. So technically only the record type changes. Nothing else.
> How is that even a higher level of interaction?
> 
> There are other services requiring admins to create DNS records
> (Google Apps for example). They are being used.

---

From: Noah Kantrowitz <[email-masked]>
Date: Tue, 15 Dec 2015 18:31:27 -0800

> On Dec 15, 2015, at 6:26 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Not to mention the multitude of automated tools that exist out in the world that know how to, say, point a domain A/CNAME/etc at Wordpress.com or Heroku or what have you. Being able to support transparent upgrades for all those people is a pretty big deal. Combine with stuff like end-point automation (the stuff I posted about a while ago) like the possibility of having Apache or Nginx at some point the future with a directly integrated ACME client so they just turn on HTTPS without you even knowing how. Tools in these situations act on the behalf of admins which may or may not grok DNS but they certainly don't have write access to it.

--Noah

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 22:25:33 -0500

> admittedly not that often.

That is my experience as well.

And it is even worse in a home situation. I do have real DNS servers on my
net. But they are heavily integrated into development systems and flaky as
heck. Most of my home related boxen sit on the DNS server on the WiFi box
which only supports A records.

Yes.

And minimizing the amount of code people need to write to implement
the protocol is not a priority for me.

I need a protocol that will work with the ugly facts of real world
networking
like NAT boxes.

> is repetitive argument and therefore pointless.

I think you probably overstate your difficulty just slightly. I think
that if you were to make a case to the campus IT folk, you could get
them to touch the DNS one time only to insert some records that
will allow you to automate issue of certs.

But that is a much smaller ask than wanting to plug in a
challenge/response scheme into the local DNS.

To make the current protocol work in my (fairly typical) home
network, I would probably have to create some mechanism that
allows me to write out the challenge responses from the host
making the application to the machine running the outward
facing Web Servers. That is do-able but a chore.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 03:39:41 +0000

Hi Phil,

> will allow you to automate issue of certs.

Hmm. I suspect our specific, and very local to TCD, 30-years
war between campus-wide IT and the dept of comp sci hasn't
been your prime time viewing;-) IOW, you're kinda right and
kinda not. But...

... that's not entirely facetious, iirc local bitter politics
has been a part of all corporate-wide re-naming (a.k.a PKI)
projects that I've seen, and always will be.

One can draw different equally valid conclusions from that.
Mine, for now, is to try solve the low-hanging-fruit issues
and then, after that is working, go from there to try for
peace-making between those discommoded by naming politics.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 15 Dec 2015 22:57:21 -0500

On Tue, Dec 15, 2015 at 10:39 PM, Stephen Farrell <[email-masked]

> peace-making between those discommoded by naming politics.

I have not had the pleasure of that little fracas. But I have seen
more than a few just like it. One of the little known facts about
the origin of the Web was that the big attraction to users on CERN
campus was that it was finally possible to get access to all the data
that CN division had hoarded on CERNVM.

This is why minimizing the number of occasions that the DNS
config needs to be touched is so important.

---

From: Julian Dropmann <[email-masked]>
Date: Wed, 16 Dec 2015 10:22:52 +0100

If the owners of the domain decide you not to give you write access to
their zone, there is probably a reason for that.
And this reason is that _they_ want to remain in control.

So why do you even assume that you should be able to obtain a certificate
for their domain if you do not even have control over that zone?
In my opinion that is exactly the definition of what CAs should verify: If
the requester has control over the zone the CA signs the certificate for.
If the CA issues a certificate for the whole zone, it has to check if this
happens in consent with the people who have control over that entire zone,
and not just one guy running a service there.

You push this discussion in a direction where its all about ease of use for
the guy running the box to obtain a certificate.
But please explain to me then, why the host behind an A record should have
that legitimization.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 12:01:04 +0000

Julian,

> But please explain to me then, why the host behind an A record should have

I'm sorry but I am not seeing what else there is to explain.
But I'll try one more time.

I control the hosts in question and have for >10 years, even
through h/w upgrades. The university don't care that I have
been using self-signed certs for all that time and now don't
care that I can finally present a cert that verifies in a
browser. They are happy enough to trust me to not mess about
inside the college network. All of that is entirely legitimate.

S.

---

From: Julian Dropmann <[email-masked]>
Date: Wed, 16 Dec 2015 13:20:45 +0100

If they trust you with that, they could just add an ACRE specific SRV
record, and thereby delegate that privilege to create certs to you and
everything would be fine.
They were able to do this with the A record too.

I just do not find it intuitive in general that by defining any record you
do this implicitly as a domain owner.
At least I personally was not expecting this, but maybe its just me that is
so stupid.

And the question was not about whether you personally are legitimated to
create certs for your university, but whether this should be the case for
any host of every single zone.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 13:38:44 +0000

> If they trust you with that, they could just add an ACRE specific SRV

(ACRE? You mean acme I guess.)

> everything would be fine.

Yes. They could. But they won't;-)

And as it happens in my own specific case I don't want the ability
to get a cert for any name in the relevant zone, I only want to be
able to get and renew certs for the names of my web servers. So the
semantics of the thing you'd put in DNS (or the thing to which it'd
point) would likely end up quite complex. It'd end up much like an
RA is my guess, and I really don't think we want to go there yet
with acme.

> any host of every single zone.

Not "any host" but any host that runs a web server and where the
entity requesting the cert demonstrates control over that web server.
I think that is fine in general myself.

S.

---

From: Julian Dropmann <[email-masked]>
Date: Wed, 16 Dec 2015 15:09:05 +0100

> Yes. They could. But they won't;-)

Why this should not be your problem then?

> RA is my guess, and I really don't think we want to go there yet

I was not saying that you should be able to create wildcards certs or certs
for sub-zones.
The problem is quite clear: Under one single zone (excluding sub-zones) or
name (I am not sure if  I am using the correct terms here) there can be
multiple services (A, MX, SRV, etc).
So even if you only create certs for your webserver, you could use that for
other services.

> I think that is fine in general myself.

Let me rephrase that question one more time:

How should I have known that its a bad idea to put my weblog under the same
zone/name as other private stuff like email, xmpp and such, if I do not
control it (ALL) by myself?
Is there any prior work / RFC which hints that all those services of one
zone basically belong to one entity, and can "speak" for each other?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 09:39:36 -0500

> RA is my guess, and I really don't think we want to go there yet

If the requirement is for an RA, you are not going to end up with a simpler
protocol if you insist on giving people umbrellas instead.

The reason the introduction of an RA simplifies the protocol is precisely
because it removes the need to validate the RA for each cert issue. The
RA validates once (a year), is issued a PKI credential and then uses that
to authenticate each request.

Stephen's situation is not typical of Enterprise but it is very typical of
academic
and SOHO environments.

> I think that is fine in general myself.

It all depends on what your requirements are.

My immediate requirement is to make the certificate warnings 'go away' on
my internal server boxen without me spending money. They are behind a NAT
and there is no way to change that.

The NAS boxes are running a version of Linux but the whole point of getting
a package deal was to avoid maintenance issues. A proposal that requires me
to write a half dozen scripts is not going to be any easier for me to
manage than my current solution of a local CA whose root I install on every
machine when I accept it into the network.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Dec 2015 16:22:25 +0000

> In order to set up their services, they should be familiar with DNS.

Nope, not a requirement.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 12:04:04 -0500

>> In order to set up their services, they should be familiar with DNS.

Even if you are familiar with the protocol to the point of having
written your own client and server, this does not mean that your
hosting provider gives you the access required to do more than
configure a few records.

I can edit A, AAAA, MX, SPF, TXT and SRV records and that is it.

I can't set up my own DNS server because my local ISP does not offer
static IP addresses unless I pay significantly more for my service.

An 'automated' certificate issue scheme that requires me to change my
ISP configuration isn't going to be a labor saver for me.

---

From: Julian Dropmann <[email-masked]>
Date: Wed, 16 Dec 2015 18:35:18 +0100

Sorry I understand all those issues, and I also want everyone using TLS,
but I think we have to figure out another way then.

Either limit the certificate to be only usable from that origin it has been
verified from, or somehow get the consent of the domain owner. If not by
changing DNS config, it might involve some other mechanism.

But what is the reasoning here? Only because we are not able to find a way
to do it properly automated we have the right to skip the domain owner,
removing him from the equation?

On Wed, Dec 16, 2015 at 6:04 PM, Phillip Hallam-Baker <[email-masked]

---

From: Peter Bowen <[email-masked]>
Date: Wed, 16 Dec 2015 11:03:52 -0800

> changing DNS config, it might involve some other mechanism.

I think you are somewhat confused.  Certificates are not for full
zones, they only name specific FQDNs.  So a certificate for
"example.com" is not valid for www.example.com or foo.example.com.
Similarly, beta.example.com is not good for example.com or
www.beta.example.com.

RFC 6125 (https://tools.ietf.org/html/rfc6125) covers how certificates
how to do name matching for certificates.  Note that SRVname is the
standard was for things identified via SRV records.

Thanks,
Peter

---

From: Michael Wyraz <[email-masked]>
Date: Wed, 16 Dec 2015 20:29:22 +0100

> Similarly, beta.example.com is not good for example.com or
Peter, I think you missunderstood him. This is not about zones or FQDNs.
It's about the fact that one who can create a cert for mydomain.com via
http-01 (because A-record delegates to him) can use this cert for every
service at domain.com, even when they are located elsewhere (e.g. via MX
or SRV).

---

From: Michael Wyraz <[email-masked]>
Date: Wed, 16 Dec 2015 20:29:57 +0100

This discussion is more and more about the question if ACME should use a
SRV record instead of a A record (as a replacement).

Personally I think that using an optional SRV record for ACME with
fallback to A record would be the best solution for all use cases. Those
who can not or don't want to setup a SRV record for ACME can use http-01
as it is. Those who sets SRV for ACME can exactly specify which host is
allowed to to ACME http-01.

An optional ACME SRV record in the spec would make all happy: Those who
only have A-record. Those who want to create certs for devices that
cannot answer to the challenge (e.g. switches). Those who have geo-based
dns (while A-record is geo-dependent, ACME SRV would point to one single
location). Those with multiple load-balances backends. And even those
who simply don't want anyone to create certs who has an A-record
delegated to (like Julian, he can simply create such a record and point
it to NIL).

Oh and of course the programmers of the acme client (no change needed
for most-common use case) and server (just a few more lines of
dns-lookup-code to determine the host to which they need to talk for
challenge).

I can't see any drawbacks this change would bring to ACME, LE or it's users.

Kind regards,
Michael.

---

From: Michael Wyraz <[email-masked]>
Date: Wed, 16 Dec 2015 20:38:03 +0100

Oops, should both be mydomain.com ;-)

> did you mean mydomain.com <http://mydomain.com> and domain.com
> <http://domain.com>, two entirely separate SLDs?
>
> On Wed, Dec 16, 2015 at 2:29 PM, Michael Wyraz <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>     > "example.com <http://example.com>" is not valid for
>     www.example.com <http://www.example.com> or foo.example.com
>     <http://foo.example.com>.
>     > Similarly, beta.example.com <http://beta.example.com> is not
>     good for example.com <http://example.com> or
>     > www.beta.example.com <http://www.beta.example.com>.
>     >
>     It's about the fact that one who can create a cert for
>     mydomain.com <http://mydomain.com> via
>     service at domain.com <http://domain.com>, even when they are
>     located elsewhere (e.g. via MX
>     or SRV).
>
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
> konklone.com <https://konklone.com> | @konklone
> <https://twitter.com/konklone>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 14:53:59 -0500

> I can't see any drawbacks this change would bring to ACME, LE or it's users.

Just a point of clarification. This would be an SRV record for the
ACME *Challenge response validation protocol*. That is a quite
different matter from having an SRV record for the ACME protocol.

The difference is that the two go in completely opposite directions
and identify parties acting in precisely the opposite roles.

So I suggest using _acme-validate._tcp and _acme-issue._tcp for the
SRV prefixes.

This would certainly allow some cleanup of the client implementations.
I might set up a daemon to run once a day that has a list of all the
certificates that particular host needs to run. It then fires off a
cert request for anything that is nearing expiry and then listens for
a challenge on whatever port the challenge is going to arrive.

In a NAT environment, I would create a separate external domain name
and SRV record for each host and give each one a different port
number. These would then fan out to the corresponding cert maintenance
daemon at the NAT.

The alternative to using SRV would be to do 'something' with CAA. But
I think that is best reserved for putting an RA key there.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 19:54:28 +0000

On 16/12/15 19:29, Michael Wyraz wrote:
> 
> An optional ACME SRV record in the spec would make all happy:

tl;dr: No, it would not make me happy and I will object to it.

Sorry about that but it's just a bad idea;-)

We'd need something like the public suffix list for that to
work. I really don't want the basic mechanism for acme to
depend on dbound. [1] If someone suggests walking the DNS
tree to find the RR, then that'll not be accepted by DNS
folks - there's lots of history for how that discussion
goes.

And even if/when the public suffix issue is sorted, it'd
still be a bad idea for people in my specific situation.
For example, a record in tcd.ie (which is the correct public
suffix) could prevent me from getting down.dsg.cs.tcd.ie certified
even though the nearest real DNS authority is for cs.tcd.ie who
probably would not publish such a record. That would push me
back to using self-signed certs which would mean that acme was
a step backwards, not forwards. Again, I don't know what the
numbers are like for folks in my situation, but every time I
have described it, people have recognised it as not uncommon.

And even if none of that were an issue, I want (me and others)
to be able to use acme to deal with CAs without there being
a new complex RA interaction as a part of the basic mode of
operation. An optional SRV scheme would inevitably evolve to
have that level of complexity. In my case, cs.tcd.ie if they
wanted to publish such a record would need a way to point to
different PIs (i.e. people) in the department as being the
ones who were responsible for authorizing certification
requests. And those people would decide to delegate that to
some student, so we'd have all sorts of non-trivial delegation
issues to tackle if the SRV scheme is to be well-defined.
Even optional things need to be well-defined.

By all means define an SRV based challenge but I will argue
strongly against it's inclusion as an option in the basic
mechanism. I will also argue against the basic mechanism
having any documentation dependency on such a scheme (because
I think it'll take 1-2 more years to get done right). OTOH,
if acme gets the basics done and soon and deployed, then I'll
be happy to try help with subsequent work on RA features.

Cheers,
S.

[1] https://tools.ietf.org/wg/dbound/

---

From: Michael Wyraz <[email-masked]>
Date: Wed, 16 Dec 2015 21:11:14 +0100

Stephen,

I fear I have no idea what you mean with a "suffix list" and such. Maybe
it's what Phillip pointed out in his mail a few minutes ago. I mean a
SRV record for ACME challenge/response that replaces the A record for
this use case if pressent.

Example:
mydomain.com. IN A 1.1.1.1
sub1.mydomain.com. IN A 2.2.2.2
sub2.mydomain.com. IN A 3.3.3.3
_acme-validate._tcp.sub2.mydomain.com. IN SRV 80 acme.mydomain.com.
sub3.mydomain.com. IN A 4.4.4.4
_acme-validate._tcp.sub3.mydomain.com. IN SRV 8080 sub3.mydomain.com.

ACME server would expect the challenge's response:
for mydomain.com at http://mydomain.com/.well-kown/...
for sub1.mydomain.com at http://sub1.mydomain.com/.well-kown/...
for sub2.mydomain.com at http://acme.mydomain.com/.well-kown/...
for sub3.mydomain.com at http://sub3.mydomain.com:8080/.well-kown/...
for subsub.sub2.mydomain.com at
http://subsub.sub2.mydomain.com/.well-kown/...

That's exactly the way MX works for mail and SRV works for those
services that uses it. It behaves exactly as with A, so if the zone contains
other.mydomain.com. IN NS sometwherelse.com.
This NS can A records as well as _acme-validate._tcp SRV records for
other.mydomain.com and all it's subdomains.

So just don't add this SRV record and you will be as happy as you are at
the moment (probably more happy since xmas is comming ;-) )

Kind regards,
Michael.

---

From: Michael Wyraz <[email-masked]>
Date: Wed, 16 Dec 2015 21:15:28 +0100

Phillip,

thank you a lot for this clarification. I meant exactly what you wrote.
Supporting such a  _acme-validate._tcp SRV record would allow people to
de-couple their webserver infrastructure from their certificate
deployment infrastructure and would be a bit advantage for automated
cert generation in more complex setups while leaving the simple setups
be simple.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 20:27:27 +0000

On 16/12/15 20:11, Michael Wyraz wrote:
> Stephen,
> 
> I fear I have no idea what you mean with a "suffix list" and such. 

(Caveat: I'm very much an amateur at DNS issues, I hope someone
else provides a better/more accurate response if one's needed.)

Pretty much all mechanisms of the kind you envisage end up
requiring a way to allow the "real" authority for a set of
names to control what happens deeper in the hierarchy. So
tcd.ie could decide what cs.tcd.ie are allowed to do with
acme for example. That means you end up needing to know
roughly where the zone cuts are, which is a hard problem
in general. The public suffix list is how that's mostly
done in the web and dbound is (an IETF activity) trying to
tease apart the various uses of that.

So one of the problems with what you suggest is that the
"right" place to look for my web servers is two up in the
hierarchy and not the public suffix and not one up.

S.

> Maybe

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 15:29:30 -0500

> folks - there's lots of history for how that discussion

I have no idea how this relates to the choice of A or SRV records.

CAs already have to cope with the public suffix list issues. That
has been part of being a CA since forever.

> have described it, people have recognised it as not uncommon.

We already went through all that on RFC6844 (CAA).

CAs are required to climb the tree. BUT to be compliant with the
specification, they are only required to state what they do when
authorization is denied.

The assumption built into CAA is that if someone delegates part of a
domain, they are also delegating the cert issue authority. So
cs.tcd.ie does not get to set policy for down.dsg.cs.tcd.ie once they
have delegated control of the DNS there.

> have that level of complexity.

I don't see how SRV makes things more complex. That might be
because I am more comfortable with SRV or it might be because I
think the basic A record validation is a bigger can of worms than you
imagine.

The complication factor here isn't the use of SRV vs A record, it
is the decision to automate. We have automated systems but
they will fallback to manual processes when a corner case is
encountered. Trying to cover every corner case is what is making
this a lot hairy-er.

> In my case, cs.tcd.ie if they

Consider pi.dsg.cs.tcd.ie, a $5 Raspberry Pi.

* Might it require a TLS cert? - Yes!
* Might it need this to be a WebPKI cert? - Possibly not.
* Should this be a wildcard cert for *.tcd.ie? - EEEK!

The thing that probably isn't obvious to folk who don't operate PKI is
that if the cert isn't a WebPKI cert, it is almost certainly going to
have to be issued under an RA to be any use to anyone at all.

So what looks like a useful tool to remove your student's need for a
WebPKI and a reduction in vulnerability actually opens up the
requirements you don't want to consider.

> be happy to try help with subsequent work on RA features.

I think it will take exactly as long to understand the nature of the
problem regardless of the nature of the solutions you accept.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 16 Dec 2015 15:32:46 -0500

> hierarchy and not the public suffix and not one up.

No, that isn't what we do for DV certs unless they are wildcard certs.

You are not going to be issuing wildcard certs with this mousetrap
built in this particular way for a long time.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Dec 2015 20:37:21 +0000

> built in this particular way for a long time.

Right. But any proposal to use SRV for a DV-equivalent seems to
me to open this can of worms. Feel free to write the I-D that
shows that I'm wrong though as I may well be misinterpreting
what Michael or you mean.

S.