On Mon, Oct 22, 2018 at 10:13 AM Kas <kas=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. > 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 <kas=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 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 >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
