On 10/22/2018 5:40 PM, Richard Barnes wrote:
On Mon, Oct 22, 2018 at 10:13 AM Kas <[email protected]
<mailto:[email protected]>> 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.
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
<[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
