On 10/22/2018 6:10 PM, Richard Barnes wrote:
On Mon, Oct 22, 2018 at 10:57 AM Kas <k...@lightc.com
<mailto:k...@lightc.com>> wrote:
On 10/22/2018 5:40 PM, Richard Barnes wrote:
On Mon, Oct 22, 2018 at 10:13 AM Kas
<kas=40lightc....@dmarc.ietf.org
<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
<kas=40lightc....@dmarc.ietf.org
<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 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 <http://example.com> or
staging.acme.example.com
<http://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
<http://mozilla.com> or android.com <http://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 <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org <mailto:Acme@ietf.org>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme
