Re: [Acme] Please consider adding server authentication

[Kas <[e-mail]>]

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