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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/acme
