Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

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

> On 10/25/2018 12:49 AM, Eric Rescorla wrote:
>
> 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.
>
> 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.

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

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.


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


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

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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/25/2018 12:49 AM, Eric Rescorla wrote:

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



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.
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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 2:36 PM Kas  wrote:

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

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.


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

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 

Re: [Acme] Please consider adding server authentication

[Kas]

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

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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 1:21 PM Kas  wrote:

>
> On Wed, Oct 24, 2018 at 12:04 PM Kas 
> 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.
>

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.


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).
>
> 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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/24/2018 10:13 PM, Salz, Rich wrote:

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.

By ignore i meant the points 2 and 3 not me.


On 10/24/2018 10:14 PM, Ilari Liusvaara wrote:

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


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


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).
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.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

On Wed, Oct 24, 2018 at 12:04 PM Kas 
wrote:

>
>
> On 10/24/2018 8:44 PM, Albert ARIBAUD wrote:
> > Hi,
> >
> > Le Wed, 24 Oct 2018 19:15:49 +0300
> > Kas  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,
> 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.
> >
> > Can you please describe the specific attack you have in mind?
> >
> > -Ekr
> >
>
> 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 :
>

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.


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

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

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
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Ilari Liusvaara]

On Wed, Oct 24, 2018 at 10:02:09PM +0300, Kas wrote:
> 
> 
> 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.
> > 
> > Can you please describe the specific attack you have in mind?
> > 
> > -Ekr
> > 
> 
> 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 :

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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

>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,
> ...
>5_ Acme editors know that along with most of you but choose to ignore 

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.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/24/2018 8:44 PM, Albert ARIBAUD wrote:

Hi,

Le Wed, 24 Oct 2018 19:15:49 +0300
Kas  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,

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.


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

-Ekr



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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Albert ARIBAUD]

Hi,

Le Wed, 24 Oct 2018 19:15:49 +0300
Kas  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.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Eric Rescorla]

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

>
> On 10/24/2018 4:39 PM, Alan Doherty wrote:
> > 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)
> 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 ?
>
> >> 1_ OpenSSL heartbleed went undetected for almost 2 years.
> > this had nothing to do with certs, all to do with the underlying
> encription implementation
> Vulnerabilities are everywhere and they are in implementations
>
> >> 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
> 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
>
> >> 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
> 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 !
>
> >> ( 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)
> 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
>
> >> 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)
> Read about the case of DigiNotar
>
> >> 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
> 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 YYY 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 YY
>
> >> and i am here not 

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/24/2018 4:39 PM, Alan Doherty wrote:

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



1_ OpenSSL heartbleed went undetected for almost 2 years.

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

Vulnerabilities are everywhere and they are in implementations


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



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



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



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)

Read about the case of DigiNotar


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
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 YYY 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 YY



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 

Re: [Acme] Please consider adding server authentication

[Alan Doherty]

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 

Re: [Acme] Please consider adding server authentication

[Kas]

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


On 10/24/2018 2:13 AM, Alan Doherty wrote:


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)



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

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 

Re: [Acme] Please consider adding server authentication

[Alan Doherty]

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)


>>by design only public information is transmitted between the acme-client and 
>>acme-server
>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)>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:
>>>On 10/23/2018 4:52 PM, Alan Doherty wrote:
again your talking about stuff unrelated to acme
(and unlikely to potentially effect acme)
>>>It is related to ACME.
your talking about inherent problems with https (or all public key 
cryptography)
(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 ?
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 

Re: [Acme] Please consider adding server authentication

[Kas]

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 ?



On 10/23/2018 7:45 PM, Alan Doherty wrote:

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:

On 10/23/2018 4:52 PM, Alan Doherty wrote:

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

It is related to ACME.

your talking about inherent problems with https (or all public key cryptography)
(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 ?

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

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 

Re: [Acme] Please consider adding server authentication

[Alan Doherty]

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:
>On 10/23/2018 4:52 PM, Alan Doherty wrote:
>>again your talking about stuff unrelated to acme
>>(and unlikely to potentially effect acme)
>It is related to ACME.
>>your talking about inherent problems with https (or all public key 
>>cryptography)
>>(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 ?
>>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
>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.

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 

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/23/2018 4:52 PM, Alan Doherty wrote:

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

It is related to ACME.

your talking about inherent problems with https (or all public key cryptography)
(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 ?

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




At 13:52 23/10/2018  Tuesday, Kas wrote:

On 10/23/2018 2:47 PM, Salz, Rich wrote:

I don't know, there is many ways, but most likely someone will design an

 attack out of this and use it.
 
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.

Re: [Acme] Please consider adding server authentication

[Ilari Liusvaara]

On Tue, Oct 23, 2018 at 12:28:12PM +0200, Sebastian Nielsen wrote:
> 
> 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.

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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Alan Doherty]

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:
>On 10/23/2018 2:47 PM, Salz, Rich wrote:
>>>I don't know, there is many ways, but most likely someone will design an
>> attack out of this and use it.
>> 
>>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 

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/23/2018 2:47 PM, Salz, Rich wrote:

I don't know, there is many ways, but most likely someone will design an

 attack out of this and use it.
 
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.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

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

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



___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Sebastian Nielsen]

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  För Kas
Skickat: den 23 oktober 2018 11:27
Till: Alan Doherty ; Salz, Rich ;
Richard Barnes ; acme@ietf.org
Ämne: Re: [Acme] Please consider adding server authentication

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.


On 10/23/2018 12:01 PM, Alan Doherty wrote:
>> 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)
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme



smime.p7s
Description: S/MIME Cryptographic Signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

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.



On 10/23/2018 12:01 PM, Alan Doherty wrote:

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)


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme




___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Alan Doherty]

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


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

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 think we’re struggling to understand the issue you are trying to raise.



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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

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


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/22/2018 7:14 PM, Salz, Rich wrote:


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



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
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/22/2018 6:10 PM, Richard Barnes wrote:



On Mon, Oct 22, 2018 at 10:57 AM Kas > wrote:



On 10/22/2018 5:40 PM, Richard Barnes wrote:

On Mon, Oct 22, 2018 at 10:13 AM Kas
mailto:40lightc@dmarc.ietf.org>> wrote:

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 ?


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.


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

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





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.


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


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

On 10/22/2018 3:48 PM, Richard Barnes wrote:

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
mailto:40lightc@dmarc.ietf.org>> wrote:

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 

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

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

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

On Mon, Oct 22, 2018 at 10:57 AM Kas  wrote:

>
> On 10/22/2018 5:40 PM, Richard Barnes wrote:
>
> On Mon, Oct 22, 2018 at 10:13 AM Kas 
> wrote:
>
>> 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 ?
>>
>
> 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.
>

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


> 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.
>>
>
> This sentence should cause you concern.  Nothing is forever in security.
>
> 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
>>
>> On 10/22/2018 3:48 PM, Richard Barnes wrote:
>>
>> 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 
>> wrote:
>>
>>> 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 

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

On Mon, Oct 22, 2018 at 10:13 AM Kas 
wrote:

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

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.


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

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



>
> Best regards,
> K. Obaideen
>
> On 10/22/2018 3:48 PM, Richard Barnes wrote:
>
> 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 
> wrote:
>
>> 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 )

Re: [Acme] Please consider adding server authentication

[Kas]

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:

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


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


___
Acme mailing list
Acme@ietf.org 
https://www.ietf.org/mailman/listinfo/acme



___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

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

> 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
>
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme