Subject: [Acme] Please consider adding server authentication

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 14:05:02 +0300

It will be regrettable and unfortunate moment to pass on such 
opportunity to make the internet more secure, and please let me start 
with listing the facts:

1_ ACME Server is CA server, if you consider it a CA server then you 
don't need a third party to validate and secure the connection with such 
server.
2_ DANE is great but will not be adopted and needs years or a 
catastrophic failure by some CA to go mainstream, simply too many 
parties has it in conflict with their business model.
3_ SPF and DKIM are used in plain TXT DNS records and they already 
securing the internet the world.
4_ ACME protocol is utilizing DNS TXT record to authenticate the client 
so both server and client has DNS handling procedure.
5_ There is huge security hole in providing the root certificates to 
secure the internet, and in most cases it depends on the system store, 
many antivirus software installs with default settings to intercept 
HTTPS connection by injecting their own root certificate in system, many 
things can go wrong with system store, even extensions in a browser can 
do that.

So why not authenticate ACME server in different way than DANE TLSA 
record and utilize TXT record similar to DKIM and make it a obligatory, 
this will allow two parties to securely communicate with only one 
requirement to trust one ACME server they already asking it for 
certificates, those parties can build secure internet environment based 
on one ACME server, even this protocol can evolve in future to issue 
certificates with only IP and no domain name, is that something wrong ?

(listing few ideas, examples)
"acme.TLSA" TXT here you can copy the whole content of TLSA record in 
JSON format encoded in base64url ( may be too much )
"acme.certs" TXT list the hash of the acme server certificates for 
secure connection ( shouldn't be the root or CA certificate )
"acme.ckeys" TXT list the the certificates public keys in JWK format 
with base64url encoding ( shouldn't be the root or CA certificate )
"acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK 
(base64url) format this key can be used to authenticate responses from 
acme server or only one critical response

"acme.dir" TXT the directory url encoded with base64url ( in this case 
the client only need the server domain name like example.com or 
staging.acme.example.com to get the acme directory )
"acme.chain" TXT url to download acme server certificate chain in secure 
manner
"acme.store" TXT url to download the mini store for that acme server 
certificate trust in secure manner ( if this adopted then there will be 
many store provider like mozilla.com or android.com the client 
application can get his own store form his own sources, client trust 
Microsoft and its store but he can't be sure the store copy in his 
Windows is not tainted )

Please consider discussion this.

Best regards
K. Obaideen

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2018 08:48:44 -0400

Hi Kas,

Before launching into mechanism, maybe you could clarify what
authentication property you think is lacking here?

Note that ACME already has server authentication, via TLS server
authentication.  All the normal PKI mitigations apply there: CT, HPKP,
etc.  It is also already the case that the CA can issue certificates for
its ACME server; no third party is needed.

Thanks,
--Richard

On Mon, Oct 22, 2018 at 7:06 AM Kas <kas=[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 17:12:41 +0300

Hi Richard,

The weak point here is the TLS connection so the question is :
How to prevent man in the middle from issuing a compromised certificate 
to automated client ?
or How to make sure TLS connection is not compromised ?

TLS require self signed root certificates and CA certificate and this 
compromise the client implementation and put weak points allowing 
attacks or failure due to expired certificates ( compromised system ...) 
, all of this can be prevented without waiting for/(or forcing) DANE by 
implementing similar approach.
By adding such mechanism client can work securely forever, no 
certificate to expire or revoke, such feature will eliminate the 
depending on system provided CA certificates or any third-party source.

Best regards,
K. Obaideen

On 10/22/2018 3:48 PM, Richard Barnes wrote:
> etc.  It is also already the case that the CA can issue certificates 
> for its ACME server; no third party is needed.
>
> Thanks,
> --Richard
>
> On Mon, Oct 22, 2018 at 7:06 AM Kas <kas=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     the client only need the server domain name like example.com
>     <http://example.com> or
>     staging.acme.example.com <http://staging.acme.example.com> to get
>     the acme directory )
>     many store provider like mozilla.com <http://mozilla.com> or
>     android.com <http://android.com> the client
>     [email-masked] <mailto:[email-masked]>

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2018 10:40:22 -0400

On Mon, Oct 22, 2018 at 10:13 AM Kas <kas=[email-masked]>
wrote:

> How to prevent man in the middle from issuing a compromised certificate to
> automated client ?
>

I don't understand what you're proposing here.  There's nothing we can do
in a protocol to stop a CA from issuing any certificate it wants to.
(That's why we have Baseline Requirements, audits, etc.)

Are you worried about a MitM causing the real CA to issue a certificate to
the MitM?  That risk is already addressed in ACME, but using *client*
authentication, not server authentication -- what matters is the client
from which the server accepts domain proof and a CSR, not what server the
client thinks it's talking to.

> compromise the client implementation and put weak points allowing attacks
> or failure due to expired certificates ( compromised system ...) , all of
> this can be prevented without waiting for/(or forcing) DANE by implementing
> similar approach.
> By adding such mechanism client can work securely forever, no certificate
> to expire or revoke, such feature will eliminate the depending on system
> provided CA certificates or any third-party source.
>

This sentence should cause you concern.  Nothing is forever in security.

As I noted above, there is already no need for third-party resources.

--Richard

---

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 17:56:04 +0300

On 10/22/2018 5:40 PM, Richard Barnes wrote:
> On Mon, Oct 22, 2018 at 10:13 AM Kas <kas=[email-masked] 
>     How to prevent man in the middle from issuing a compromised
>     certificate to automated client ?
>
>
> I don't understand what you're proposing here.  There's nothing we can 
> do in a protocol to stop a CA from issuing any certificate it wants 
> to.  (That's why we have Baseline Requirements, audits, etc.)
>
> Are you worried about a MitM causing the real CA to issue a 
> certificate to the MitM?  That risk is already addressed in ACME, but 
> using *client* authentication, not server authentication -- what 
> matters is the client from which the server accepts domain proof and a 
> CSR, not what server the client thinks it's talking to.
I am concerned about MitM issuing the certificate to the client.

>     TLS require self signed root certificates and CA certificate and
>     this compromise the client implementation and put weak points
>     allowing attacks or failure due to expired certificates (
>     compromised system ...) , all of this can be prevented without
>     waiting for/(or forcing) DANE by implementing similar approach.
Using forever was wrong, i shouldn't say that.

> As I noted above, there is already no need for third-party resources..
>
> --Richard
>
>
>     Best regards,
>     K. Obaideen
>
>>     authentication.  All the normal PKI mitigations apply there: CT,
>>     HPKP, etc.  It is also already the case that the CA can issue
>>     certificates for its ACME server; no third party is needed.
>>
>>     Thanks,
>>     --Richard
>>
>>         staging.acme.example.com <http://staging.acme.example.com> to
>>         get the acme directory )

---

From: Richard Barnes <[email-masked]>
Date: Mon, 22 Oct 2018 11:10:40 -0400

> I am concerned about MitM issuing the certificate to the client.

Why does the MitM even need ACME for this?  Can't it just issue the
certificate?

Maybe your concern is that the MitM could convince the client to install
and serve TLS using a certificate of the MitM's choosing.  I can see how
that could be harmful, e.g., if the certificate had improper SANs in it.
This is addressed to a degree in the Operational Considerations [1], but
could probably be improved.  In any case, the right mitigation for this
risk is for the client to verify that the certificate chain looks sane
before installing it, since even the correct server could provide a
malicious cert chain.

[1] https://tools.ietf.org/html/draft-ietf-acme-acme-16#section-11.4

---

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 19:13:26 +0300

On 10/22/2018 6:10 PM, Richard Barnes wrote:
>
>
> On Mon, Oct 22, 2018 at 10:57 AM Kas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>>     I don't understand what you're proposing here.  There's nothing
>>     we can do in a protocol to stop a CA from issuing any certificate
>>     it wants to.  (That's why we have Baseline Requirements, audits,
>>     etc.)
>>
>>     certificate to the MitM?  That risk is already addressed in ACME,
>>     but using *client* authentication, not server authentication --
>>     what matters is the client from which the server accepts domain
>>     proof and a CSR, not what server the client thinks it's talking to.
> Maybe your concern is that the MitM could convince the client to 
> install and serve TLS using a certificate of the MitM's choosing.  I 
> can see how that could be harmful, e.g., if the certificate had 
> improper SANs in it.  This is addressed to a degree in the Operational 
> Considerations [1], but could probably be improved.  In any case, the 
> right mitigation for this risk is for the client to verify that the 
> certificate chain looks sane before installing it, since even the 
> correct server could provide a malicious cert chain.
Exactly, MitM can issue a certificate with his own SAN, so how to 
validate a chain properly without third party ? what if the MitM has 
issued to the client a certificate with known trusted CA by the system, 
against what should the client validate and verify such certificate and 
its chain ?

I don't see a way to verify a chain without third party ( trusted or 
known) as all root certificate are self-signed, how much time do you 
think is needed before changing this protocol to enforce DANE, DANE 
should be enforced long time ago but it will not happen any soon, and on 
other hand why repeat the process DKIM went through, till now it is not 
enforced but don't expect your email to reach its destination without 
proper DKIM.
My point is don't waste this opportunity to implement the protocol the 
right way, all what you need is something like those examples i wrote, 
and here another one :
in many server client application i wrote i used PSK ( pre-shared key) , 
server has a RSA public key in DNS TXT record and the client use it to 
encode his random generated pre-shared key and send it as hint to the 
server.

My intention is not wasting anyone time, just explaining a point that 
can be problem in the future, and i am sure all of you can reach the 
perfect solution.

Best regards
K. Obaideen

>>         TLS require self signed root certificates and CA certificate
>>         and this compromise the client implementation and put weak
>>         points allowing attacks or failure due to expired
>>         certificates ( compromised system ...) , all of this can be
>>         prevented without waiting for/(or forcing) DANE by
>>         certificate to expire or revoke, such feature will eliminate
>>         the depending on system provided CA certificates or any
>>         third-party source.
>>
>>
>>>         Before launching into mechanism, maybe you could clarify
>>>         what authentication property you think is lacking here?
>>>
>>>         Note that ACME already has server authentication, via TLS
>>>         server authentication.  All the normal PKI mitigations apply
>>>         there: CT, HPKP, etc. It is also already the case that the
>>>         CA can issue certificates for its ACME server; no third
>>>         party is needed.
>>>
>>>         Thanks,
>>>         --Richard
>>>
>>>             the client only need the server domain name like
>>>             example.com <http://example.com> or
>>>             staging.acme.example.com
>>>             <http://staging.acme.example.com> to get the acme
>>>             directory )
>>>             many store provider like mozilla.com
>>>             <http://mozilla.com> or android.com <http://android.com>
>>>             the client

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Oct 2018 16:14:54 +0000

*   Are you worried about a MitM causing the real CA to issue a certificate to the MitM?  That risk is already addressed in ACME, but using *client* authentication, not server authentication -- what matters is the client from which the server accepts domain proof and a CSR, not what server the client thinks it's talking to.
  *   I am concerned about MitM issuing the certificate to the client.

I am confused.  You are worried about an attacker “intercepting” the ACME connection and issuing a certificate to the client?
It is not necessary to add more “protection” at the TLS layer to protect against this.  The client can verify the signed certificate, and CA chain, that comes back.  DANE is not widely used, and it seems like a mistake to require it for ACME.

---

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 19:50:40 +0300

On 10/22/2018 7:14 PM, Salz, Rich wrote:
>
>   * Are you worried about a MitM causing the real CA to issue a
> I am confused.  You are worried about an attacker “intercepting” the 
> ACME connection and issuing a certificate to the client?
>
> It is not necessary to add more “protection” at the TLS layer to 
> protect against this.  The client can verify the signed certificate, 
> and CA chain, that comes back.  DANE is not widely used, and it seems 
> like a mistake to require it for ACME.
>
Hi Richard,

My suggestion with something similar to DANE and DKIM (in utilizing DNS 
and DNSSEC), DNS TXT record is already been used by acme protocol to 
pass a challenge, so why not use similar implementation to authenticate 
the server itself for the client, so the client can verify the 
certificate and the chain, without a third-party.
You are the expert editors and contributors here, it is your job will 
decide to do this on ACME protocol layer or TLS layer, in both case it 
should use DNS TXT record and stay away from waiting for DANE or 
depending on external resources.

Best regards,
K. Obaideen

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Oct 2018 17:24:22 +0000

*   My suggestion with something similar to DANE and DKIM (in utilizing DNS and DNSSEC), DNS TXT record is already been used by acme protocol to pass a challenge, so why not use similar implementation to authenticate the server itself for the client, so the client can verify the certificate and the chain, without a third-party.

No third-party is needed.  The client has to trust *something* out of band.  In a browser, this is typically the root store, and any CA trust chain should end up being signed by something in that store.  Other clients have different methods, but they are ultimately a set of trusted “root anchors.”  If you put data in DNS, then the client has to trust DNS and the chain that signed that data.

I think we’re struggling to understand the issue you are trying to raise.

---

From: Kas <[email-masked]>
Date: Mon, 22 Oct 2018 21:39:17 +0300

On 10/22/2018 8:24 PM, Salz, Rich wrote:
>
>   * My suggestion with something similar to DANE and DKIM (in
>     utilizing DNS and DNSSEC), DNS TXT record is already been used by
>     acme protocol to pass a challenge, so why not use similar
>     implementation to authenticate the server itself for the client,
>     so the client can verify the certificate and the chain, without a
>     third-party.
>
> No third-party is needed.  The client has to trust **something** out 
> of band.  In a browser, this is typically the root store, and any CA 
> trust chain should end up being signed by something in that store.  
> Other clients have different methods, but they are ultimately a set of 
> trusted “root anchors.”  If you put data in DNS, then the client has 
> to trust DNS and the chain that signed that data.
>

I am not trying to raise an issue, client can only trust acme server 
simply by providing a key (public key) along with the ACME URL, you 
trust example.com then put in your library this url and this key 
supplied by example.com service, thus the client doesn't need to trust 
anything else, by such key any MitM can be detected by both client and 
server or just one, that depends on how you tweak this protocol, that 
key can be supplied to the library by implementer, user or DNSSEC (in 
this case you need a key) .

Acme server is CA server and shouldn't need a root store to be validated 
or trusted, that root store can be easily manipulated even by a 
software, even without locally manipulation the MitM can issue a 
certificate to the client by simply hijacking the connection and having 
certificate issued by trusted CA, and the client will validate and trust 
that certificate.

Again i am sorry that you feel i am raising an issue, i am not, only 
suggesting a concerning matter to discuss.

Best regards and sorry for wasting your time,
K. Obaideen

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 22 Oct 2018 19:03:37 +0000

*   I am not trying to raise an issue

Yes, that is exactly what you are doing.  Raising an issue for discussion.  It’s just the terminology we use.

  *   Acme server is CA server and shouldn't need a root store to be validated or trusted, that root store can be easily manipulated even by a software, even without locally manipulation the MitM can issue a certificate to the client by simply hijacking the connection and having certificate issued by trusted CA, and the client will validate and trust that certificate.

I thought you were concerned about client’s being attacked by MiTM?

At any rate, you didn’t waste anyone’s time.  Open discussion is the purpose.

---

From: Alan Doherty <[email-masked]>
Date: Tue, 23 Oct 2018 10:01:47 +0100

>Acme server is CA server and shouldn't need a root store to be validated or trusted, that root store can be easily manipulated even by a software, even without locally manipulation the MitM can issue a certificate to the client by simply hijacking the connection and having certificate issued by trusted CA, and the client will validate and trust that certificate.

how would this scenario be an attack???

if the mitm gives over a valid cert to the 'victim'-client
what have they achieved?

they have viewed otherwise public information that is useless to them, and 'victim' operations are uninterrupted
(as obviously an acme client (as with all CA operations) never reveals the private key to a CA or any other parties, as only the public ones transit the wire)
and gained 0 information/resources of use (and expended a lot of effort to mitm successfully, by somehow obtaining a trusted cert for the CA endpoint their impersonating)

---

From: Kas <[email-masked]>
Date: Tue, 23 Oct 2018 12:25:17 +0300

Revoke it and make all clients of the client mark the victim untrusted 
at a moment fits the attacker scheme, or make clients of the victim 
request CRL url to disturb a network, or get list of a client endpoints, 
cause trouble for a monitored network when the clients looks like 
accessing some specific IP or site.

I don't know, there is many ways, but most likely someone will design an 
attack out of this and use it.

---

From: "Sebastian Nielsen" <[email-masked]>
Date: Tue, 23 Oct 2018 12:28:12 +0200

I agree with alan here. The ACME protocol is designed such as you don't need
to trust the server (and/or any MITM) particularly much.
Even the challenges are protected since you need to SHA-256 the token with
your client key to aquire the valid token value.
(If the challenges would not be protected this way, a attacker could replace
the token values with their own, which also has a pending authorization for
the victims domain)

This means an attacker cannot MITM an ACME server such as the attacker would
get a valid certificate for the victim domain.

-----

The only danger I could see is if the attacker MITMs the account-creation
process, then they could also MITM the rest, replacing everything with their
own values, and thus fooling a ACME client into authorizing a domain for an
attacker.

But I have a solution to this, and that is a CAA revocation mechanism:
[OPTIONAL] If the ACME client receives a certificate from the CA server, for
which it does not own the private key to, or is not the certificate the ACME
client ordered, is not signed by a valid CA, or any other mismatchs, it may
change its CAA record into "revoke" and then the CA's name.
like this:
example.com. CAA 0 revoke "letsencrypt.org"

The CA server should periodically query the CAA record and if it sees any
"revoke" posts with its own CA name, it should trigger an revocation for any
and all certificates that this current DNS name owns.
The query period could be constructed as a "smart back-off" algoritm, where
it queries the CAA record more often the hour the certificate was issued,
and then cools down into querying once a day for like an week, and then
after that, querying weekly.

Also, it might be smart if the server, upon processing a revocation request,
could query the CAA record (regardless of when it did query it last,
provided any rate limits for failed authorizations aren't met), and if it
finds a revoke tag, it will process the revocation request as valid
regardless of which account key signed the request.

Also, in this case I think it should NOT require ownership of all domains in
a certficate as it does for normal revocation checking, due to this should
be a "emergency function" to block all certificates issued to a domain if a
cert has been fraudulently issued.
The tag "revoke" should override both issue and issuewild, meaning that any
issue and issuewild bearing the same CA name as the revoke tag should be
ignored.

The reason im proposing a CAA revocation mechanism, is that once the
attacker has gained a certificate, he could block the access to the CA
server, preventing the ACME client from requesting any revocation. By
allowing a scheme where the ACME client can post a revoke CAA tag, and then
wait until the CA server reads it, a ACME client can easily recover from a
compromised certificate.

-----Ursprungligt meddelande-----
Från: Acme <[email-masked]> För Kas
Skickat: den 23 oktober 2018 11:27
Till: Alan Doherty <[email-masked]>; Salz, Rich <[email-masked]>;
Richard Barnes <[email-masked]>; [email-masked]
Ämne: Re: [Acme] Please consider adding server authentication

>> Acme server is CA server and shouldn't need a root store to be validated
or trusted, that root store can be easily manipulated even by a software,
even without locally manipulation the MitM can issue a certificate to the
client by simply hijacking the connection and having certificate issued by
trusted CA, and the client will validate and trust that certificate.
> (as obviously an acme client (as with all CA operations) never reveals the
private key to a CA or any other parties, as only the public ones transit
the wire)
> and gained 0 information/resources of use (and expended a lot of effort to
mitm successfully, by somehow obtaining a trusted cert for the CA endpoint
their impersonating)

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Oct 2018 11:47:50 +0000

If so (and I doubt it), such an attack would work on any web server/client combination, and is not specific to ACME.

---

From: Kas <[email-masked]>
Date: Tue, 23 Oct 2018 15:52:18 +0300

> If so (and I doubt it), such an attack would work on any web server/client combination, and is not specific to ACME.

I don't have the mind set to think like an attacker, in internet 
security you can be astonished how attackers think, but let say you can 
only manage to know when a server (lets say university campus server) 
will request a certificate then all what you need is to make sure dns 
pointed to your laptop, and continue with the issuance the certificate, 
now you can utilize the CRL url in your certificate to make the victim 
clients makes call to an illicit url, monitored by the authority and 
that url let them download 50mb (crl request doesn't have size limit), 
how the victims can explain their phones and laptops downloaded such 
things, and here is the kick, the security software installed on the PC 
might make that request, those requests are not monitored by the system 
and most likely will bypass any firewall.

I completely agree many of those attacks not specific to ACME, but with 
ACME it's concerning the parties in contact with the victim, and ACME 
has the ability to prevent and enhance the internet in overall.

The core of the problem is with root store and who to trust, 15-20 years 
ago downloading a root store and verify it was something alien and 
unaccepted, now downloading 5mb can take few seconds and verifying it 
take way less, acme server can issue certificates using more than one CA 
certificate even it might have more than one root certificate, so why 
not to supply mini store so the clients of acme server can communicate 
in secure manner without trusting the system or any pre-supplied data, 
they just download the root store from example.com and you are good to 
go, all what is needed is acme URL or DNS with a key for DNSSEC or a key 
supplied by the ACME server itself.

The current internet has well defined security protocols but in many 
cases depends on weak points, while creating new draft for such lets say 
root store will not go further than a draft or may be a RFC without 
adoption, and that why acme protocol and this draft has the power to 
change all of that, i am not calling for reinventing the wheel but to 
put a seed for better and secure internet, this seed might replace the 
crippled wheel, this draft will be mass adopted and i know this out of 
scope of this protocol intended usage, but still it has the power and 
the opportunity to do so, and on top of that you all who can make that 
happen, just think out of the box, and discuss this in depth, will this 
be best practice or bad practice? will such expansion to this protocol 
make the internet more secure or useless waste of time ? does such extra 
measures to secure the certificate issuance contradict with other RFC or 
enhance them?

Please don't only think about this as how to prevent an attack (one or 
many) because what can go wrong will do, and this draft does have way 
more power and ability to move things very far in security, and i trust 
you can do good by at least discussing the big picture and how things 
will be in few years from now, as whole current system is wired with 
human factor administrating few key points, and all those secure castles 
are waiting for one CA server to fail and this will disturb the whole 
internet to its core.

---

From: Alan Doherty <[email-masked]>
Date: Tue, 23 Oct 2018 14:52:17 +0100

again your talking about stuff unrelated to acme
(and unlikely to potentially effect acme)

your talking about inherent problems with https (or all public key cryptography)
(thus only addressable/fixable by https related ietf groups)

acme cannot (and should not) expect its users to develop/run/use software with an otherwise completely non-standard https implementation
(and thus missing any improvements/bug-fixes etc within wider https protocol/libraries)

it uses https because its an existing/maintained/developed widely available protocol (and will improve with any underlying improvements to the base protocol)

but acme is designed to use https not for security, just for transport
its security is designed to be in the data sent/received so eavesdropping (mitm) cannot be advantageous to 3rd parties

and yes many improvements could be added to https but as all automatable ones can be as effectively be intercepted by a suitably technically proficient mitm  (if you check dns, mitm dns) if you check 3rd party (mitm 3rd pary) etc etc
if its visual check key on a webpage (regexp replace good/bad key on all traffic to victim mitm his whole internet)
only 100% secure method is out of band (phone sms etc. even these can be mitm if your a state level actor)

thats why the improvements to https are made elsewhere and rigorously tested adopted/abandoned by that community

thats why we rely on browsers/https libraries to secure themselves 
usually based on arrives with trusted keys, trusts updates to this list that are signed with an already trusted one
imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the client or wire

At 13:52 23/10/2018  Tuesday, Kas wrote:
>I don't have the mind set to think like an attacker, in internet security you can be astonished how attackers think, but let say you can only manage to know when a server (lets say university campus server) will request a certificate then all what you need is to make sure dns pointed to your laptop, and continue with the issuance the certificate, now you can utilize the CRL url in your certificate to make the victim clients makes call to an illicit url, monitored by the authority and that url let them download 50mb (crl request doesn't have size limit), how the victims can explain their phones and laptops downloaded such things, and here is the kick, the security software installed on the PC might make that request, those requests are not monitored by the system and most likely will bypass any firewall.
>
>I completely agree many of those attacks not specific to ACME, but with ACME it's concerning the parties in contact with the victim, and ACME has the ability to prevent and enhance the internet in overall.
>
>The core of the problem is with root store and who to trust, 15-20 years ago downloading a root store and verify it was something alien and unaccepted, now downloading 5mb can take few seconds and verifying it take way less, acme server can issue certificates using more than one CA certificate even it might have more than one root certificate, so why not to supply mini store so the clients of acme server can communicate in secure manner without trusting the system or any pre-supplied data, they just download the root store from example.com and you are good to go, all what is needed is acme URL or DNS with a key for DNSSEC or a key supplied by the ACME server itself.
>
>The current internet has well defined security protocols but in many cases depends on weak points, while creating new draft for such lets say root store will not go further than a draft or may be a RFC without adoption, and that why acme protocol and this draft has the power to change all of that, i am not calling for reinventing the wheel but to put a seed for better and secure internet, this seed might replace the crippled wheel, this draft will be mass adopted and i know this out of scope of this protocol intended usage, but still it has the power and the opportunity to do so, and on top of that you all who can make that happen, just think out of the box, and discuss this in depth, will this be best practice or bad practice? will such expansion to this protocol make the internet more secure or useless waste of time ? does such extra measures to secure the certificate issuance contradict with other RFC or enhance them?
>
>
>Please don't only think about this as how to prevent an attack (one or many) because what can go wrong will do, and this draft does have way more power and ability to move things very far in security, and i trust you can do good by at least discussing the big picture and how things will be in few years from now, as whole current system is wired with human factor administrating few key points, and all those secure castles are waiting for one CA server to fail and this will disturb the whole internet to its core.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 23 Oct 2018 17:31:52 +0300

> own values, and thus fooling a ACME client into authorizing a domain for an

I do not think this attack works. The incorrect key would cause the CA
to compute different key authorization than the client (because they
disagree about the key with client) and the validations would fail.

And the attacker can not make CA use matching KA, as that would
require access to client key which signs the requests preventing
modification, and which attacker does not have, or breaking SHA-256.

Now if you are talking about non-acme, then the CABForum approved
validation methods do indeed allow validations that are vulernable to
such MITM attacks.

Now, while attacker that can MITM the client->server connection can
not misissue, he can still try to send maliscous input to the client,
which then triggers all sorts of trouble, from DoS atacks to possible
RCE on the client.

-Ilari

---

From: Kas <[email-masked]>
Date: Tue, 23 Oct 2018 17:56:36 +0300

> (and unlikely to potentially effect acme)
It is related to ACME.
> (thus only addressable/fixable by https related ietf groups)
https uses TLS which utilize certificates issued by acme to be validated 
against root certificates , so acme is involved or can be, and what RFC 
(draft or protocol ) control that root certificates store ?  How did you 
get it ? why not included the last process involving the store and the 
certificates issued by ACME in this protocol instead waiting for another 
draft ?
> imperfect but perfection is impossible (all we can add is hoops to jump, restrictions etc) but all automated public-key checks can obviously themselves be compromised if you have access to the clie…
How is https relevant here ? even TLS is irrelevant as it all will go to 
root store and its source, MitM can issue attacks against the parties 
that will use the compromised certificate to establish trusted secure 
connection.

You are missing the point, this protocol has the chance to standardize 
this root store and its source, and it is shame to pass it, at least to 
acme issued certificates and this will not contradict any existing 
protocol and doesn't require any change anywhere, so in theory you can 
build a secure bullet proof network where all the parties start with 
trusting one acme provider with no root store provided by any third 
party, and this can be the seed or motivation for other older CA's to 
follow, even OS's can follow and use the same protocol not to issue a 
certificate but to supply their root store in secure way , imagine your 
ability to configure a browser lets say Chrome running on Windows OS to 
use the root store provided by Mozilla, now Chrome is using the Windows 
certstore which is easy to be tampered with and its content can't be 
100% updated.

 >thats why we rely on browsers/https libraries to secure themselves
Exactly , non-standardized process which allow a browser extension to 
inject root certificate in those libraries, and by non-standardized i 
mean there is no unified and securely designed process to update and 
ensure the root updated and secure, each browser and each system has its 
own method, and most of them require full update for the software before 
updating that root store, and acme has good chance to fix that, or at 
least do its part.

---

From: Alan Doherty <[email-masked]>
Date: Tue, 23 Oct 2018 17:45:10 +0100

no certificate can be 'compromised'
all certificates are public information by nature (everyone attempting to connect to a https site sees the public-cert thus mitm seeing it moments before it becomes public is pointless and moot)

only private keys (known only to the client and never transmitted)
can be 'compromised'

by design only public information is transmitted between the acme-client and acme-server

At 15:56 23/10/2018  Tuesday, Kas wrote:
>https uses TLS which utilize certificates issued by acme to be validated against root certificates , so acme is involved or can be, and what RFC (draft or protocol ) control that root certificates store ?Â  How did you get it ? why not included the last process involving the store and the certificates issued by ACME in this protocol instead waiting for another draft ?
>How is https relevant here ? even TLS is irrelevant as it all will go to root store and its source, MitM can issue attacks against the parties that will use the compromised certificate to establish trusted secure connection.
>
>You are missing the point, this protocol has the chance to standardize this root store and its source, and it is shame to pass it, at least to acme issued certificates and this will not contradict any existing protocol and doesn't require any change anywhere, so in theory you can build a secure bullet proof network where all the parties start with trusting one acme provider with no root store provided by any third party, and this can be the seed or motivation for other older CA's to follow, even OS's can follow and use the same protocol not to issue a certificate but to supply their root store in secure way , imagine your ability to configure a browser lets say Chrome running on Windows OS to use the root store provided by Mozilla, now Chrome is using the Windows certstore which is easy to be tampered with and its content can't be 100% updated.
>
>Exactly , non-standardized process which allow a browser extension to inject root certificate in those libraries, and by non-standardized i mean there is no unified and securely designed process to update and ensure the root updated and secure, each browser and each system has its own method, and most of them require full update for the software before updating that root store, and acme has good chance to fix that, or at least do its part.

by defining a standard or central root store you define a simple method to compromise all
atm its only the wide variety of methods used that frustrates the efforts of any attempt at widspread compromise
(ie you can see browserX is compromised because browserY shows an issue) as both use separate root stores defined by their maintainers

no in-band method is possibly secure, so having a wide range of different non-standard ways and sources a user can verify their root store (to frustrate attempts at possibly intercepting all)
again security/insecurity of https clients is NOTHING to do with a CA's job (which is providing a verifiable signature to client public keys ONLY)

acme is ONLY about automating the CAs job nothing to do with what the certs are used/useable for afterwards
nothing to do with the underlying design of https

---

From: Kas <[email-masked]>
Date: Tue, 23 Oct 2018 20:14:13 +0300

Can MitM impersonate acme server and walk the client through the whole 
process and issue a certificate to the client ? yes it can.

If your understanding to 'compromised' certificate is leaked private 
key, then this certificate is not 'compromised', only MitM issued it for 
his own intentions and the last thing he care about is making the client 
secure or any party will connect to that client. Right ?

Client ask acme server for a certificate and get a certificate issued by 
MitM not the real and right acme server, do you consider such 
certificate 'compromised' or not ? (while private key is still secret)

What if this MitM issued certificate and supplied a chain to self-signed 
certificate to the false ( compromised without leaking private key but 
issued for bad intentions ) certificate , then client should validate 
the chain, that is easy and understandable, when reaching to that 
self-signed certificate how to trust it ?

 >by design only public information is transmitted between the 
acme-client and acme-server
How to authenticate acme-server ?
and how to authenticate such server in cloud based service lets say acme 
server is using service like CloudFlare ?

---

From: Alan Doherty <[email-masked]>
Date: Wed, 24 Oct 2018 00:13:33 +0100

At 18:14 23/10/2018  Tuesday, Kas wrote:
>Can MitM impersonate acme server and walk the client through the whole process and issue a certificate to the client ? yes it can.
>
>If your understanding to 'compromised' certificate is leaked private key, then this certificate is not 'compromised', only MitM issued it for his own intentions and the last thing he care about is making the client secure or any party will connect to that client. Right ?
>
>Client ask acme server for a certificate and get a certificate issued by MitM not the real and right acme server, do you consider such certificate 'compromised' or not ? (while private key is still secret)

if the cert is usable then it is no more/less secure than the one from the CA direct
(the cert being a signature from a widely trusted CA verifying the public key the client provided, is authentically from the client)

if the cert is unuasable (untrusted) the client/user/etc can detect this
 
>What if this MitM issued certificate and supplied a chain to self-signed certificate to the false ( compromised without leaking private key but issued for bad intentions ) certificate , then client should validate the chain, that is easy and understandable, when reaching to that self-signed certificate how to trust it ?

?? i think you again miss what a cert is and how x509 works 
issued for bad intentions?  the acme-client is the only one who can use the cert (as the only one with the private key)
the CA has no input or control over the use of the cert (so their intent affects nothing)

>How to authenticate acme-server ? no need
>and how to authenticate such server in cloud based service lets say acme server is using service like CloudFlare ? again no need

an acme client gives not one jot of care about if they are talking to their CA or another (well they do but only insofar as getting a cert that works)
only that the cert they get is valid/invalid

if a rouge CA can somehow miraculously issue valid certs, ones trusted by others and me then its as i said no concern

they could cause outage by refusing service long enough for my valid certs to expire, they cannot cause outage/compromise or any other issue by issuing valid certs
issuing invalid certs is the same as refusing service but more costly effort wise for the mitm thus pointless

i have a private key, i have a public key, i the acme-client-owner created both
a cert is just
((my public key)+a cryptographic signature vouching for its authenticity from my-CA)<<varies client to client
+(my-CAs public key)+a cryptographic signature vouching for its authenticity from their CA)<<invariant for however many CAs till root
+(their CAs public key)+.....till a trusted root                                           

i give my CA my public key, and the identity(s) i wish to use, they require i prove im who i claim to be, i do so
they send back the varient part of the cert, the invariant part i can obtain publicly or from my CA (the copy of the chain)
i can then verify all against as many/few trusted root stores of browsers i want (or just simpler/faster compare the current chain against previous, as they do not vary often)

(only generate-able by the owner of my CAs private key(my CA)
publicly verifiable by being signed by my-CAs public key (verifiable by looking at their CA etc)

so to issue a valid cert a mitm can only possibly direct my cert request to myCA or another-trustedCA but cannot possibly generate a cert themselves without first compromising a trusted (by me) CAs private key
if they have achieved this then they already have ownership of the CA and thus have no need to mitm

their only job is to assure the browser that my public key is valid
if the browser trusts me (if cert untrusted/self signed) or my cert they then send me data/receive data from me and encrypt/decrypt with this public key
(and i can send/receive using my private key for same)

either way the data they send/receive is no more/less secure due to the x509 cert
my users would be as secure with me if i used self signed certs to talk to me, the use of a trusted CA is just to assure strangers (those that have not otherwise verified my authenticity) that mysite.com is not an imposter

but everyone has mysite.com's cert (its public) only mysite.com can use it to talk as only mysite has the private key necessary to send people data that can be decrypted by the public key embedded in that public cert

---

From: Kas <[email-masked]>
Date: Wed, 24 Oct 2018 13:02:33 +0300

Certificate is not just a public key, it has extensions well defined and 
standardized in RFC's, please educate your self with them, how and when 
they should handled and what actions they might trigger, and remember 
this: implementation of such handling is something can't be controlled 
and let me list few facts :

1_ OpenSSL heartbleed went undetected for almost 2 years.

2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf 
file ( handcrafted file with bad intentions) , imagine yourself opening 
a pdf file and losing the warranty of your phone .( though many people 
used that pdf intentionally )

3_ Many client software's like browsers or email clients like 
Thunderbird will add every CA certificate automatically to their store ( 
their own store or the system store ) , MitM can issue CA certificate to 
a client which is in this case SMTP server and this server will use that 
certificate and help distribute this "compromised without losing the 
privatekey" certificate to everyone comes in contacting with that SMTP 
server.

4_ Keeping private key secret is a MUST, but this doesn't means you 
should trust the certificate from unknown sources, as they might be 
targeting your clients not you.( handcrafted with bad intentions)

5_ What if a company like Samsung wanted to issue certificates to its 
devices to make the connections between phones and TV secure, and it 
don't want to ask Apple and Microsoft to add Samsung root certificate to 
theirs system store, then Samsung can't use acme protocol or it can ? 
and i am here not pointing the monopoly in such addition but we are in 
2018 and that root store should be more secure and obtained online from 
the source in secure way, should you accept and install such root 
certificate manually from every device or simply go to Samsung site and 
import the their root and store and you are good to go with all their 
devices, is that doable ? is that practical and safer for the average 
user of the internet ?

The question is so simple if A asked B for certificate how A can be sure 
there is no M in the middle issued the certificate ? if the answer by 
depending on TLS layer then that is not a solution, as all will come to 
validates a root self-signed certificate, so that question will become 
how A obtain the root certificate from B to validates the issued 
certificate ?

This draft can ignore this issue, and that is OK, but it can do better 
and resolve what really needs resolving the root issue, and help 
internet become more safe and secure, not for this specific protocol but 
as a seed for other protocols to follow, how many RFC's been used by 
this draft and how many in the future will depends on this draft ( soon 
to be RFC).

That been said ,and i really don't want to discuss attacks because it is 
useless and endless discussion, so please Alan first forgive my English 
(may be i wasn't clear) and pretty please don't steer the this 
thread/subject away from its topic.

Best reagrds,

K. Obaideen

---

From: Alan Doherty <[email-masked]>
Date: Wed, 24 Oct 2018 14:39:43 +0100

At 11:02 24/10/2018  Wednesday, Kas wrote:
>Certificate is not just a public key, it has extensions well defined and standardized in RFC's, please educate your self with them, how and when they should handled and what actions they might trigger, and remember this: implementation of such handling is something can't be controlled and let me list few facts :

the functional part of a cert is just the public key (
all the rest and the extentions are just wrapping to give details of who else is vouching for it and what identities it is associated with)

>1_ OpenSSL heartbleed went undetected for almost 2 years.

this had nothing to do with certs, all to do with the underlying encription implementation

>2_ Hackers managed to jailbreak Apple iPhone by simply opening a pdf file ( handcrafted file with bad intentions) , imagine yourself opening a pdf file and losing the warranty of your phone .( though many people used that pdf intentionally )

again nothing to do with certs

>3_ Many client software's like browsers or email clients like Thunderbird will add every CA certificate automatically to their store

none will the entire point of the trusted root store is its involitility
a user can add roots manually but 0 software will update its root store except by normal (to it) software update

> ( their own store or the system store ) , MitM can issue CA certificate to a client which is in this case SMTP server and this server will use that certificate and help distribute this "compromised without losing the privatekey" certificate to everyone comes in contacting with that SMTP server.

thats patently impossible, otherwise new CAs could just use this method to gain trustinstead of the current hoop jumping amd auditing they have to go through to get included in software root stores
(why letsencrypt for example is signed by their own and other(extant in older sofware) roots till their own is widespread as software updates the signatures from other older CAs are needed (to ensure at least one of the root signitures is in potential clients root store) 

>4_ Keeping private key secret is a MUST, but this doesn't means you should trust the certificate from unknown sources, as they might be targeting your clients not you.( handcrafted with bad intentions)

again as long as it passes my validation (signed by 1 or more widely trused roots) it is doing its job (passing and verifying my public key)

>5_ What if a company like Samsung wanted to issue certificates to its devices to make the connections between phones and TV secure, and it don't want to ask Apple and Microsoft to add Samsung root certificate to theirs system store, then Samsung can't use acme protocol or it can ? 

it wouldnt prevent them at all
or adding their own CAs root to the trusted roots on all future devices

>and i am here not pointing the monopoly in such addition but we are in 2018 and that root store should be more secure and obtained online from the source in secure way, should you accept and install such root certificate manually from every device or simply go to Samsung site and import the their root and store and you are good to go with all their devices, is that doable ? is that practical and safer for the average user of the internet ?

many do CA cert for example (widely used by many before acme) and not included in most browser softwares root stores 
but those wishing to use manually added them to their own CA root store and advised their users/customers to do same
and some software did include them

anyone can setup a CA there is no central authority
every large enteprise tends to have their own CA to issue certs only seen/used internally and updates all internal machines to trust this CAs signiture

to get included in mozillas root store you have to pass their audits, then you get included
to get included in microsofts same
to get included i librayX's same etc

some root stores trust others audit process' and auto trust any root audited/added by another
some root store maintainers will

there can (and shouldn't) be any single central authority  

>The question is so simple if A asked B for certificate how A can be sure there is no M in the middle issued the certificate ? if the answer by depending on TLS layer then that is not a solution, as all will come to validates a root self-signed certificate, so that question will become how A obtain the root certificate from B to validates the issued certificate ?

if the cert returned is signed by B then whoever signed it has B's private key (thus must be B)
no mitm can see any information that is not safe to leak (by design)
 
>This draft can ignore this issue, and that is OK, but it can do better and resolve what really needs resolving the root issue, and help internet become more safe and secure, not for this specific protocol but as a seed for other protocols to follow, how many RFC's been used by this draft and how many in the future will depends on this draft ( soon to be RFC).

the issue of which roots are trusted is again nothing to do with acme
(acme can be used by private CAs, public untrusted CAs (like ca cert), and public widely trusted CAs (like letsenrypt)

its just a means of transmitting the public key needing signed, authorising the identities to be verified, and obtaining the signed public key (cert) back from the CA that the acme client has chosen 

the client chooses the CA based on their needs (if they want a widely trusted one, they use one) publicly accessable webservers for instance
if they care not about its trustability because of narrow audience (https interfaces of routers/firewalls etc) they will often use self signed or signed by an internal/enterprise CA 

*i say widely because there are infinite software developers, all with differing lists of trusted by them roots so no CA can be assured their current roots public key has been added to all (its why some software delegates trust/verification to the OS or another)

its also why as time passes a CA may sign its intermediate public cert with its expiring in a few years old-root key and its valid for many more new-roots key (because much software wont yet have the new root key trusted, and no way to force same) due to involitile by design trusted root store

(why when lenovo software auto-added its own root to all windows root store computers their software ran on their was such outcry as their private key for this root was widely known and thus anyone could easily sign certs that would be trusted by these 'victim' computers)
found by users comparing their root stores to others 

>That been said ,and i really don't want to discuss attacks because it is useless and endless discussion, so please Alan first forgive my English (may be i wasn't clear) and pretty please don't steer the this thread/subject away from its topic.
>
>
>Best reagrds,
>
>K. Obaideen
>
>

---

From: Kas <[email-masked]>
Date: Wed, 24 Oct 2018 19:15:49 +0300

> all the rest and the extentions are just wrapping to give details of who else is vouching for it and what identities it is associated with)
Wrong and you should not look at a certificate as a public key, please 
educate yourself with deeper understanding what do extensions serve and 
what critical extension means, i have a Code Signing certificate can i 
use it for IIS ? it has a public key ! and it been vouched by Comodo , 
do you understand what is CRL Distribution Points(2.5.29.31) and how 
that certificate should be checked before considered trusted ?

> this had nothing to do with certs, all to do with the underlying encription implementation
Vulnerabilities are everywhere and they are in implementations

> again nothing to do with certs
Certs are ASN.1 a data structure language and can be utilized to 
compromise a remote device, please search the web for "asn.1 
vulnerability" every system and many software got hacked by using 
handcrafted certificate, in my example how a pdf (Portable Document 
Format) file compromised a system

> a user can add roots manually but 0 software will update its root store except by normal (to it) software update
I said CA certificate not root certificate there is difference, CA's in 
most cases will be added automatically to the store as long the root in 
the store, and some will add it as not trusted without root but in many 
cases will be added !

> (why letsencrypt for example is signed by their own and other(extant in older sofware) roots till their own is widespread as software updates the signatures from other older CAs are needed (to ensu…
There is CA certificates providers and they are sell it, an attacker can 
get one from on by stealing the private key of one, it is not something 
impossible or didn't happen

> again as long as it passes my validation (signed by 1 or more widely trused roots) it is doing its job (passing and verifying my public key)
Read about the case of DigiNotar

> or adding their own CAs root to the trusted roots on all future devices
Right, now how to update or revoke those certificate and keep the 
devices working wouldn't be easier and safe that you bought a TV and the 
paper guide instruct you to put X.com (it has by default) in settings 
and apply the key YYYYYYY if that didn't work then visit X.com and get 
the updated key after that it will be automated process, now to access 
that device form you PC instead of accepting the root and install it ( 
or adding it to exclusion) you do the same use X and YYYYYY

> there can (and shouldn't) be any single central authority
I know how certificates and store works,
If your store from Microsoft then your CA controlled by Microsoft ,while 
FireFox on Windows has Mozilla store, so how many stores out there and 
where you get them ?
This should be unified or separated and i can't care less about that, 
the whole point is to define how to obtain the store/root of specific CA 
online in a secure way, acme can do that staring by its server, it 
already has online certificate revocation process that can be adopted by 
every CA out there.

Sorry i don't feel like reading and answering the rest because i am lost 
and can't understand what is your point, is it to proof i am wrong in my 
suggestion ?( no need to answer that ), you keep steering the subject 
away, and i don't know if the editors got my point or even will have the 
mood of reading any of this,

Thank you and pretty please Alan give it rest, you proved me wrong and won !

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 10:30:08 -0700

Kas,

I've read through this entire thread, and TBH, I really don't understand
what threat you are concerned with.

Can you please describe the specific attack you have in mind?

-Ekr

On Wed, Oct 24, 2018 at 9:18 AM Kas <kas=[email-masked]> wrote:

> >> Certificate is not just a public key, it has extensions well defined
> and standardized in RFC's, please educate your self with them, how and when
> they should handled and what actions they might trigger, and remember this:
> implementation of such handling is something can't be controlled and let me
> list few facts :
> > all the rest and the extentions are just wrapping to give details of who
> else is vouching for it and what identities it is associated with)
> file ( handcrafted file with bad intentions) , imagine yourself opening a
> pdf file and losing the warranty of your phone .( though many people used
> that pdf intentionally )
> Thunderbird will add every CA certificate automatically to their store
> >> ( their own store or the system store ) , MitM can issue CA certificate
> to a client which is in this case SMTP server and this server will use that
> > thats patently impossible, otherwise new CAs could just use this method
> to gain trustinstead of the current hoop jumping amd auditing they have to
> go through to get included in software root stores
> > (why letsencrypt for example is signed by their own and other(extant in
> older sofware) roots till their own is widespread as software updates the
> signatures from other older CAs are needed (to ensure at least one of the
> root signitures is in potential clients root store)
> > again as long as it passes my validation (signed by 1 or more widely
> trused roots) it is doing its job (passing and verifying my public key)
> devices to make the connections between phones and TV secure, and it don't
> want to ask Apple and Microsoft to add Samsung root certificate to theirs
> system store, then Samsung can't use acme protocol or it can ?
> 2018 and that root store should be more secure and obtained online from the
> source in secure way, should you accept and install such root certificate
> manually from every device or simply go to Samsung site and import the
> their root and store and you are good to go with all their devices, is that
> doable ? is that practical and safer for the average user of the internet ?
> > many do CA cert for example (widely used by many before acme) and not
> included in most browser softwares root stores
> > but those wishing to use manually added them to their own CA root store
> and advised their users/customers to do same
> > every large enteprise tends to have their own CA to issue certs only
> seen/used internally and updates all internal machines to trust this CAs
> signiture
> >
> >> The question is so simple if A asked B for certificate how A can be
> sure there is no M in the middle issued the certificate ? if the answer by
> validates a root self-signed certificate, so that question will become how
> A obtain the root certificate from B to validates the issued certificate ?
> and resolve what really needs resolving the root issue, and help internet
> become more safe and secure, not for this specific protocol but as a seed
> for other protocols to follow, how many RFC's been used by this draft and
> how many in the future will depends on this draft ( soon to be RFC).
> > (acme can be used by private CAs, public untrusted CAs (like ca cert),
> and public widely trusted CAs (like letsenrypt)
> >
> > its just a means of transmitting the public key needing signed,
> authorising the identities to be verified, and obtaining the signed public
> key (cert) back from the CA that the acme client has chosen
> >
> > the client chooses the CA based on their needs (if they want a widely
> trusted one, they use one) publicly accessable webservers for instance
> > if they care not about its trustability because of narrow audience
> (https interfaces of routers/firewalls etc) they will often use self signed
> or signed by an internal/enterprise CA
> >
> > *i say widely because there are infinite software developers, all with
> differing lists of trusted by them roots so no CA can be assured their
> current roots public key has been added to all (its why some software
> delegates trust/verification to the OS or another)
> >
> > its also why as time passes a CA may sign its intermediate public cert
> with its expiring in a few years old-root key and its valid for many more
> new-roots key (because much software wont yet have the new root key
> trusted, and no way to force same) due to involitile by design trusted root
> store
> >
> > (why when lenovo software auto-added its own root to all windows root
> store computers their software ran on their was such outcry as their
> private key for this root was widely known and thus anyone could easily
> sign certs that would be trusted by these 'victim' computers)
> >> That been said ,and i really don't want to discuss attacks because it
> is useless and endless discussion, so please Alan first forgive my English
> >>>> Can MitM impersonate acme server and walk the client through the
> whole process and issue a certificate to the client ? yes it can.
> >>>>
> >>>> Client ask acme server for a certificate and get a certificate issued
> by MitM not the real and right acme server, do you consider such
> >>> (the cert being a signature from a widely trusted CA verifying the
> public key the client provided, is authentically from the client)
> >>>
> >>>> What if this MitM issued certificate and supplied a chain to
> self-signed certificate to the false ( compromised without leaking private
> key but issued for bad intentions ) certificate , then client should
> validate the chain, that is easy and understandable, when reaching to that
> >>> issued for bad intentions?  the acme-client is the only one who can
> use the cert (as the only one with the private key)
> >>>> and how to authenticate such server in cloud based service lets say
> acme server is using service like CloudFlare ? again no need
> >>> an acme client gives not one jot of care about if they are talking to
> their CA or another (well they do but only insofar as getting a cert that
> works)
> >>> if a rouge CA can somehow miraculously issue valid certs, ones trusted
> by others and me then its as i said no concern
> >>>
> >>> they could cause outage by refusing service long enough for my valid
> certs to expire, they cannot cause outage/compromise or any other issue by
> issuing valid certs
> >>> ((my public key)+a cryptographic signature vouching for its
> authenticity from my-CA)<<varies client to client
> >>> +(my-CAs public key)+a cryptographic signature vouching for its
> authenticity from their CA)<<invariant for however many CAs till root
> >>> i give my CA my public key, and the identity(s) i wish to use, they
> require i prove im who i claim to be, i do so
> >>> they send back the varient part of the cert, the invariant part i can
> obtain publicly or from my CA (the copy of the chain)
> >>> i can then verify all against as many/few trusted root stores of
> browsers i want (or just simpler/faster compare the current chain against
> previous, as they do not vary often)
> >>>
> >>> so to issue a valid cert a mitm can only possibly direct my cert
> request to myCA or another-trustedCA but cannot possibly generate a cert
> themselves without first compromising a trusted (by me) CAs private key
> >>> if the browser trusts me (if cert untrusted/self signed) or my cert
> they then send me data/receive data from me and encrypt/decrypt with this
> public key
> >>> my users would be as secure with me if i used self signed certs to
> talk to me, the use of a trusted CA is just to assure strangers (those that
> have not otherwise verified my authenticity) that mysite.com is not an
> imposter
> >>>
> >>> but everyone has mysite.com's cert (its public) only mysite.com can
> use it to talk as only mysite has the private key necessary to send people
> data that can be decrypted by the public key embedded in that public cert
> >>>

---

From: Albert ARIBAUD <[email-masked]>
Date: Wed, 24 Oct 2018 19:44:08 +0200

Hi,

Le Wed, 24 Oct 2018 19:15:49 +0300
Kas <kas=[email-masked]> a écrit:

> Wrong and you should not look at a certificate as a public key,
> please educate yourself with deeper understanding what do extensions
> serve and what critical extension means, i have a Code Signing
> certificate can i use it for IIS ? it has a public key ! and it been
> vouched by Comodo , do you understand what is CRL Distribution
> Points(2.5.29.31) and how that certificate should be checked before
> considered trusted ?

As an observer to this discussion, I would like to point out that
asking your interlocutor(s) what they know or do not know is rarely
productive, as people are usually poor judges on how well they know
some topic. Plus, even if the answer is accurate enough, it does not
help the discussion progress to a fruitful conclusion -- all the more
when the questions are asked in bursts.

I would kindly advise you to just assume that others in the discussion
know enough of the topic to understand a detailed technical argument,
and to just lay out in such detail the concrete attack scenario(s) which
you are envisioning and concrete proposal(s) for mitigation or
protection.

People on this list who do know the topic well enough will ask
meaningful questions, which will help the discussion progress. People
on this list who do not know the topic well enough may indeed ask
questions which are irrelevant or suggest solutions which are
inefficient, in which case you will be able to point out the concrete
reason for the irrelevance or inefficiency, and again, discussion will
progress toward a useful conclusion.

Amicalement,
-- 
Albert.

---

From: Kas <[email-masked]>
Date: Wed, 24 Oct 2018 22:02:09 +0300

> progress toward a useful conclusion.
Hi Albert,
Thank you for clearing that for me, you are right and i was wrong with 
such questions, in fact that paragraph was quoted with text from Alan 
and i should knew better.

On 10/24/2018 8:30 PM, Eric Rescorla wrote:
> Kas,
>
> I've read through this entire thread, and TBH, I really don't 
> understand what threat you are concerned with.
>

Hi Eric,

I am not talking about a threat or kind of attack per se, please let me 
put the points i trying to convoy in short :
1_ MitM is a threat, as there is no way for acme client to make sure he 
is talking to the intended acme server not to an impersonator, according 
to current draft of acme protocol you should :
2_ Depend on TLS layer to establish this trust and this will take us to 
root certificates supplied to the client, here i am suggesting should be 
avoided by implementing different approach as acme sever is de facto a 
trusted CA server and should be handled as such,
3_ Or consider adding to acme protocol a process to authenticate the 
server to the client, this will prevent any threats, but will raise 
different problem, the client should have the full chain to that 
certificate in secure way and can validate and match the resource 
directory url of acme server with specific root certificate to trust, 
hence my suggestion to utilize dns to publish a key ( may the root 
public key,CA's public key, a key intended to sign server response  ... 
something to authenticate the certificate and its acme server)
4_ Acme has online and automated certificate revocation protocol which 
is new, so any CA can already start to implement it even for different 
type of certificates ( eg. Code Signing ), that is great but why stop 
here and not add a process to supply the root and CA certificates 
instead on depending what client has.
5_ Acme editors know that along with most of you but choose to ignore 
that and that is fine as those points can be interpreted as irrelevant 
to this protocol but at the same time any expansion will not conflict 
with any other protocol, hence the title "Please consider" take this as 
petition to expand Acme for better internet.

and thank you

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 24 Oct 2018 19:13:42 +0000

> ...

I do not think the WG is ignoring you. Members of the WG have made significant efforts to make sure we understand you.

We just disagree with you -- that's different.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 24 Oct 2018 22:14:56 +0300

On Wed, Oct 24, 2018 at 10:02:09PM +0300, Kas wrote:
> I am not talking about a threat or kind of attack per se, please let me put
> the points i trying to convoy in short :
> 1_ MitM is a threat, as there is no way for acme client to make sure he is
> talking to the intended acme server not to an impersonator, according to
> current draft of acme protocol you should :

AFAIK, the impersonator can not tamper with the requests undetected due
to the request nonces, request signatures and key authorization including
the key  fingerprint.

Such impersonator could still try to cause denial of service (including
via feeding bogus certificate to the client) or try to attack the
client (including escape sequence attacks and protocol implementation
bugs). A well-made client should resist such attacks (other than brute
denial of service which one can not do anything with).

If you look at Let's Encrypt, they use a CDN, which is definitely not
a trusted component (nor it can be)...

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 12:15:14 -0700

> to current draft of acme protocol you should :

I don't think I agree with this claim. The client's expectations about the
intended
server are set by its domain name and it verifies that it is talking to the
server in
question via the WebPKI.

> trusted CA server and should be handled as such,

I don't understand what this means. The client doesn't take its root
certificates
from the ACME server. In fact, in the most common use cases for ACME,
issuance of WebPKI server certs, the server doesn't need to know
anything about trust anchors at all (the ACME *client* does, but
those are preinstalled and don't need to interact with the ACME server
other than doing ordinary WebPKI validation).

-Ekr

---

From: Kas <[email-masked]>
Date: Wed, 24 Oct 2018 23:19:59 +0300

> We just disagree with you -- that's different.
By ignore i meant the points 2 and 3 not me.

> a trusted component (nor it can be)...

MitM can be full acme server and and doesn't need to tamper with the 
requests on contrary he will act accordingly to this draft, acme client 
beyond establishing TLS handshake successfully had no idea to whom he is 
talking to, all what MitM needs is to intercept one DNS lookup and 
change it to his address and the attack is successful, of course the 
MitM can use a certificate issued by the real acme server, there is no 
way to distinguish a MitM acting server has letencrypt issued 
certificate from letsencrypt.com itself if both certificates has the 
same trusted root certificate.

On Wed, Oct 24, 2018 at 12:04 PM Kas <kas=[email-masked] 
<mailto:[email-masked]>> wrote:
> I don't think I agree with this claim. The client's expectations about 
> the intended
> server are set by its domain name and it verifies that it is talking 
> to the server in
> question via the WebPKI.
Acme protocol doesn't mention anything about verifying domain name, if 
you mean when on TLS connection layer then my replay to Ilari applies here.

> other than doing ordinary WebPKI validation).
Client doesn't take its root certificates from ACME server that is true, 
but when a client utilize ACME protocol to get a certificate from ACME 
server, this implies that this server is already CA trusted in the eyes 
of the client, and in both cases if the CA cert used by acme server to 
issue the certificate leads or not to a trusted root certificate on 
client side, the client want that certificate and want the full chain 
and has the power trust it or not, hence my suggestion to pin something 
in DNS TXT record may be the hash of of the server certificates used to 
accept client connections but it should not be the root( my replay to 
Ilari explain this) or public key will be used in ACME protocol to sign 
or verify all or some of the steps requesting certificate, after all 
server demand to authenticate the client by verifying ownership of the 
domain, so i am suggesting to do the same to make acme server to proof 
itself as the owner of the acme server domain to the client (not the 
same way by passing a challenge of course), but pinning something 
critical to this issued certificate, after following such secure 
mechanism client can download the root and trust it, and there is 
nothing mentioned in the draft preventing ACME server from being a 
WebPKI provider if it is not root trusted by the client.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 13:33:34 -0700

On Wed, Oct 24, 2018 at 1:21 PM Kas <[email-masked]> wrote:

> server are set by its domain name and it verifies that it is talking to
> the server in
> question via the WebPKI.
>
> Acme protocol doesn't mention anything about verifying domain name, if you
> mean when on TLS connection layer then my replay to Ilari applies here.
>

I don't understand that response. You seem to be assuming that the WebPKI
isn't secure, but htat's not the operational assumption here.

> server, this implies that this server is already CA trusted in the eyes of
> the client, and in both cases if the CA cert used by acme server to issue
> the certificate leads or not to a trusted root certificate on client side,
> the client want that certificate and want the full chain and has the power
> trust it or not,
>

This is pretty hard to follow but If I'm understanding you correctly, then
I don't think this is correct. There's just no connection at all between
the trust anchors in the ACME client and the trust anchor associated with
the CA part of the ACME server.

Consider the case where I am operating an Enterprise CA for my own servers.
This CA has a self-signed certificate X that needs to be installed in every
Web client in my network. The CA itself runs ACME and has a certificate
that's signed by a WebPKI valid anchor T. The ACME client component of my
Web server connects to my own ACME server and has trust anchor T installed,
and is therefore able to validate the ACME server's identity at the TLS
level. However, because it does not have trust anchor X installed, the ACME
server cannot issue a certificate which would be acceptable to the ACME
client [0]. Contrariwise, my Web clients have trust anchor X (and likely T)
installed, and so will accept certificates from both the ordinary WebPKI
and from my Enterprise CA.

You seem to have some concern about this, but I can't really figure out
what it is. Given that a number of people have engaged with you and seem to
also be confused, I would suggest that the problem is that you aren't being
clear. I would suggest you draw a diagram of the various states, including
the initial state, the state you would consider secure, and the state you
are concerned about.

-Ekr

[0] Note that the ACME client might have a copy of X in order to validate
the cert chain provided by the ACME server as a means of sanity checking
but this has nothing to do with the TLS portion.

---

From: Kas <[email-masked]>
Date: Thu, 25 Oct 2018 00:35:38 +0300

On 10/24/2018 11:33 PM, Eric Rescorla wrote:
>
>>     I don't understand what this means. The client doesn't take its
>>     root certificates
>     Client doesn't take its root certificates from ACME server that is
>     true, but when a client utilize ACME protocol to get a certificate
>     from ACME server, this implies that this server is already CA
>     trusted in the eyes of the client, and in both cases if the CA
>     cert used by acme server to issue the certificate leads or not to
>     a trusted root certificate on client side, the client want that
>     certificate and want the full chain and has the power trust it or
>     not,
>
>
> This is pretty hard to follow but If I'm understanding you correctly, 
> then I don't think this is correct. There's just no connection at all 
> between the trust anchors in the ACME client and the trust anchor 
> associated with the CA part of the ACME server.
>
> Consider the case where I am operating an Enterprise CA for my own 
> servers. This CA has a self-signed certificate X that needs to be 
> installed in every Web client in my network. The CA itself runs ACME 
> and has a certificate that's signed by a WebPKI valid anchor T. The 
> ACME client component of my Web server connects to my own ACME server 
> and has trust anchor T installed, and is therefore able to validate 
> the ACME server's identity at the TLS level. However, because it does 
> not have trust anchor X installed, the ACME server cannot issue a 
> certificate which would be acceptable to the ACME client [0]. 
> Contrariwise, my Web clients have trust anchor X (and likely T) 
> installed, and so will accept certificates from both the ordinary 
> WebPKI and from my Enterprise CA.
>
> You seem to have some concern about this, but I can't really figure 
> out what it is. Given that a number of people have engaged with you 
> and seem to also be confused, I would suggest that the problem is that 
> you aren't being clear. I would suggest you draw a diagram of the 
> various states, including the initial state, the state you would 
> consider secure, and the state you are concerned about.
>
> -Ekr
>
> [0] Note that the ACME client might have a copy of X in order to 
> validate the cert chain provided by the ACME server as a means of 
> sanity checking but this has nothing to do with the TLS portion.

You said "trust anchors in the ACME client and the trust anchor 
associated with the CA part of the ACME server" and in your example 
"This CA has a self-signed certificate X that needs to be installed in 
every Web client in my network."
there is connection and there will always connection between those,

There is no need for example as your example will do :
My point is about "installed" from your example as word and as process, 
ACME is Automatic Certificate Management Environment and thus if this 
"installed" can be automated then it better be, and it can be supplied 
online without preinstalled certificates, all your clients can only need 
the DNS root key and utilize DNSSEC to obtain your X, please correct me 
if i am wrong, on top of that there is RFC 5011 "Automated Updates of 
DNS Security (DNSSEC) Trust Anchors" can update that key in secure way, 
and you can revoke your CA certificate and issue another one to ACME 
server and all your client will be updated automatically, so in my 
opinion using DNSSEC is way more secure than depending on client store.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 14:49:35 -0700

On Wed, Oct 24, 2018 at 2:36 PM Kas <kas=[email-masked]> wrote:

> servers. This CA has a self-signed certificate X that needs to be installed
> in every Web client in my network. The CA itself runs ACME and has a
> certificate that's signed by a WebPKI valid anchor T. The ACME client
> component of my Web server connects to my own ACME server and has trust
> anchor T installed, and is therefore able to validate the ACME server's
> identity at the TLS level. However, because it does not have trust anchor X
> installed, the ACME server cannot issue a certificate which would be
> acceptable to the ACME client [0]. Contrariwise, my Web clients have trust
> anchor X (and likely T) installed, and so will accept certificates from
> both the ordinary WebPKI and from my Enterprise CA.
>
> You said "trust anchors in the ACME client and the trust anchor associated
> with the CA part of the ACME server" and in your example "This CA has a
> self-signed certificate X that needs to be installed in every Web client in
> my network."

Yes, there is a connection between the Web clients (e.g., browsers) and the
trust anchor in the enterprise CA, but it has nothing to do with ACME.
Generally, the way this works is that when you set up the enterprise CA,
you'd generate the trust anchor which you put into whatever system you use
to manage those clients. But ACME isn't involved at all, because the web
servers that talk to the CA are also not involved.

> the DNS root key and utilize DNSSEC to obtain your X, please correct me if
> i am wrong, on top of that there is RFC 5011 "Automated Updates of DNS
> Security (DNSSEC) Trust Anchors" can update that key in secure way, and you
> can revoke your CA certificate and issue another one to ACME server and all
> your client will be updated automatically, so in my opinion using DNSSEC is
> way more secure than depending on client store.
>

I would say three things about this:

1. This has nothing to do with ACME, which is entirely about the
interaction between the cert-holder and the CA. Speaking as AD (the rest of
this message is as an individual)  I can tell you that anything having to
do with populating the client key store would be out of scope for ACME.
2. I actually don't agree that it would be better to have the client trust
anchor store updated via DNS, at least for one of the large well-managed
clients (e.g., Firefox, Chrome, etc.)  Because of the nature of the WebPKI,
the question of whether a trust anchor is one that the client should trust
is to a great extent a policy question. and the clients (or the operating
systems that they are hosted on) operate root programs which evaluate those
policy issues  (for instance, determining whether a given CA should be
distrusted). So, the relevant question is how that information gets
communicated to the user's machine. There's no particular reason why the
DNS is a good choice for that.
3. In the particular case of enterprise trust anchors (as opposed to
preconfigured ones) there are already mechanisms for remotely managing
machines, and so again. DNS is not a particularly good mechanism for this.

-Ekr

---

From: Kas <[email-masked]>
Date: Thu, 25 Oct 2018 01:49:41 +0300

On 10/25/2018 12:49 AM, Eric Rescorla wrote:
> interaction between the cert-holder and the CA. Speaking as AD (the 
> rest of this message is as an individual)  I can tell you that 
> anything having to do with populating the client key store would be 
> out of scope for ACME.
Sure it is out of scope but supplying the chain as CA and root 
certificate doesn't conflict and will only secure the protocol, it is as 
i said you know better but adding the ability to obtain such small store 
from acme server is not bad practice.

> 2. I actually don't agree that it would be better to have the client 
> trust anchor store updated via DNS, at least for one of the large 
> well-managed clients (e.g., Firefox, Chrome, etc.)  Because of the 
> nature of the WebPKI, the question of whether a trust anchor is one 
> that the client should trust is to a great extent a policy question. 
> and the clients (or the operating systems that they are hosted on) 
> operate root programs which evaluate those policy issues (for 
> instance, determining whether a given CA should be distrusted). So, 
> the relevant question is how that information gets communicated to the 
> user's machine. There's no particular reason why the DNS is a good 
> choice for that.
DNS is running on different servers and will add extra layer of 
security, even letsencrypt as fully trusted ACME service provider by 
every store, if wanted to impersonate example.com and act as acme server 
running on example.com will fail unless it can control DNS records of 
that domain.

> machines, and so again. DNS is not a particularly good mechanism for this.
DNS can be used to deliver a pair of encoded data one url and a hash to 
a certificate to establish secure connection and obtain the chain of 
acme server, or the store from acme server contain all the root and CA 
certificates being used by that ACME server, on other hand if only one 
RFC or protocol has defined such request or protocol, then there will be 
a chance to configure Windows to use the store provided by Mozilla.
Every email been sent trigger DNS lookup to check DKIM and SPF and DNS 
servers doing amazing and fast job.

I think you got my suggestion and i don't think there will be such a 
chance to standardize such protocols/functionality in near future if 
ACME passed on it, i mean something the online certificate revocation 
process, it is ready to be used.
And i am not saying it should be DNS, i think you can figure well suited 
approach to enhance this protocol.

That is it and thank you for your time

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 16:03:30 -0700

We seem to still be talking past each other, so I'm going to try one more
time and then probably give up.

On Wed, Oct 24, 2018 at 3:50 PM Kas <kas=[email-masked]> wrote:

> Sure it is out of scope

What out of scope means here is: the ACME WG should not be working on this.
If you want to work on it, you will need a recharter or to start some other
wG.

but supplying the chain as CA and root certificate doesn't conflict and
> will only secure the protocol, it is as i said you know better but adding
> the ability to obtain such small store from acme server is not bad practice.
>

I honestly don't understand how you think this is going to work. In this
scenario, the clients have no interaction with the ACME server at all. They
may not even be on a network connected to it.

> DNS is running on different servers and will add extra layer of security,
> even letsencrypt as fully trusted ACME service provider by every store, if
> wanted to impersonate example.com and act as acme server running on
> example.com will fail unless it can control DNS records of that domain.
>

It would really help if you were able to explain what your concern is. It's
certainly true that an WebPKI-capable CA can (modulo CT, pinning, etc.)
impersonate another WebPKI CA to an ACME client, but this doesn't seem like
a very interesting threat given that said CA can impersonate *any* site to
*any* client, which is a much more serious type of attack in general. The
IETF has already standardized a set of techniques (including ones based on
DNS) for preventing this type of attack, and ACME clients are free to use
those. But there's nothing required in ACME for that.

> DNS can be used to deliver a pair of encoded data one url and a hash to a
> certificate to establish secure connection and obtain the chain of acme
> server, or the store from acme server contain all the root and CA
> certificates being used by that ACME server, on other hand if only one RFC
> or protocol has defined such request or protocol, then there will be a
> chance to configure Windows to use the store provided by Mozilla.
>

I don't understand what you think this would accomplish. As I said, there
are two cases:

- In the case of system-installed trust anchors, there is already an
existing way to configure them, and the vendors don't want to outsource
that to DNS
- In the case of user-installed (or typically systems-manager installed)
trust anchors, there are also existing ways to configure them via
enterprise policy, and DNS wouldn't be a good choice there either.

Note that neither of these cases involves any kind of connection to the
ACME server.

> chance to standardize such protocols/functionality in near future if ACME
> passed on it, i mean something the online certificate revocation process,
> it is ready to be used.

I'm sorry, I am totally unable to determine what use cases you think you
are trying to solve, and therefore I don't see how to design a protocol to
address them. Again, it would really help if you would describe a concrete
attack. Failing that, I don't think this is a productive interaction.

-Ekr