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