On Mon, Oct 22, 2018 at 10:57 AM Kas <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> > 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 > 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> >> 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
