[Acme] I-D Action: draft-ietf-acme-authority-token-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : ACME Challenges Using an Authority Token
Authors : Jon Peterson
  Mary Barnes
  David Hancock
  Chris Wendt
Filename: draft-ietf-acme-authority-token-01.txt
Pages   : 11
Date: 2018-10-22

Abstract:
   A number of proposed challenges for the Automated Certificate
   Management Environment (ACME) effectively rely on an external
   authority issuing a token according to a particular policy.  This
   document specifies a generic Authority Token challenge for ACME which
   supports subtype claims for different identifiers or namespaces that
   can be defined separately for specific applications of this Authority
   Token challenge.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-authority-token-01
https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-authority-token-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] I-D Action: draft-ietf-acme-authority-token-tnauthlist-01.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment 
WG of the IETF.

Title   : TNAuthList profile of ACME Authority Token
Authors : Chris Wendt
  David Hancock
  Mary Barnes
  Jon Peterson
Filename: draft-ietf-acme-authority-token-tnauthlist-01.txt
Pages   : 12
Date: 2018-10-22

Abstract:
   This document defines a profile of the Automated Certificate
   Management Environment (ACME) Authority Token for the automated and
   authorized creation of certificates for VoIP Telephone Providers to
   support Secure Telephony Identity (STI) using the TNAuthList defined
   by STI certificates.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-authority-token-tnauthlist/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-authority-token-tnauthlist-01
https://datatracker.ietf.org/doc/html/draft-ietf-acme-authority-token-tnauthlist-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-authority-token-tnauthlist-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ACME DV Security Considerations Draft

[Salz, Rich]

Following Ben’s suggestion, this draft is being moved to SECDISPATCH for 
discussion.

Thanks!

From: Ryan Sleevi 
Date: Sunday, October 21, 2018 at 9:01 PM
To: Benjamin Kaduk 
Cc: Rich Salz , Ryan Sleevi , Tobias 
Fiebig , "ke...@iseclab.org" , 
"acme@ietf.org" 
Subject: Re: [Acme] ACME DV Security Considerations Draft


On Sun, Oct 21, 2018 at 6:48 PM Benjamin Kaduk 
mailto:ka...@mit.edu>> wrote:
On Sun, Oct 21, 2018 at 05:25:40PM +, Salz, Rich wrote:
>   *   It does not seem to be related to ACME - that is, what you’re 
> describing is more broadly a set of concerns with the methods that may be 
> used to validate a domain.
>
> Perhaps ACME isn’t the right place for this, perhaps it should be reviewed by 
> SecDispatch, or whatever the DNS equivalent is, or coordinated between the 
> two area AD’s.

Since there are proposed solutions in here, secdispatch would seem like a
fine place (and the latest agenda I saw for them had some slots free,
still).  There might also be a place for a more open-ended discussion of
problems with DV in SAAG, if someone were to volunteer to prepare some
slides and structure the discussion.

Thanks. I agree secdispatch is probably a better place for this. The CA/Browser 
Forum's Validation WG attempted to perform a similar analysis during it's F2F 
in Herdon, VA, as captured ever so briefly in 
https://cabforum.org/2018/03/08/final-minutes-for-ca-browser-forum-f2f-meeting-herndon-va-7-8-march-2018/
 . This was the first (and only) meeting in which the Forum Chair extended 
blanket invitations for experts to participate, and while well-attended, is 
nowhere near the open participation model that the IETF represents. Work on 
attempting to resolve some of the security concerns is captured in 
http://cabforum.org/pipermail/validation
 , although the limited participation (largely of CAs) prevents a lot of the 
thorough analysis this work represents, and having a broader participation such 
as through secdispatch is better for the ecosystem as a whole.

One minor pedantic quibble, however, is that I think the discussion would be 
better served by not speaking of it as ACME or DV. The notion of "DV/OV/EV" is 
an arbitrary marketing distinction with no security value - all certificate 
types rely on the same procedures for validating an assertion of control 
(organizational or operational) over a domain name. Indeed, in many cases, 
forms of certificates such as OV/EV have been demonstrated to be significantly 
weaker in practice - for example, that the organization name in WHOIS (i.e. 
"Google, Inc") matches an incorporated institution somewhere named the same - 
without any further validation about which "Google, Inc" is being referred to, 
soft-matches such as "Google, LLC", or even relationships such as "There's a 
Google LLC as a subsidiary of Alphabet, and this company's name is Alphabets, 
so that's probably OK".

By speaking more generally of the challenges of validating a domain, we allow 
speaking with precision without the distinction of marketing or branding, and 
addressing the underlying security issues more directly.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/22/2018 8:24 PM, Salz, Rich wrote:


  * My suggestion with something similar to DANE and DKIM (in
utilizing DNS and DNSSEC), DNS TXT record is already been used by
acme protocol to pass a challenge, so why not use similar
implementation to authenticate the server itself for the client,
so the client can verify the certificate and the chain, without a
third-party.

No third-party is needed.  The client has to trust **something** out 
of band.  In a browser, this is typically the root store, and any CA 
trust chain should end up being signed by something in that store.  
Other clients have different methods, but they are ultimately a set of 
trusted “root anchors.”  If you put data in DNS, then the client has 
to trust DNS and the chain that signed that data.


I think we’re struggling to understand the issue you are trying to raise.



I am not trying to raise an issue, client can only trust acme server 
simply by providing a key (public key) along with the ACME URL, you 
trust example.com then put in your library this url and this key 
supplied by example.com service, thus the client doesn't need to trust 
anything else, by such key any MitM can be detected by both client and 
server or just one, that depends on how you tweak this protocol, that 
key can be supplied to the library by implementer, user or DNSSEC (in 
this case you need a key) .


Acme server is CA server and shouldn't need a root store to be validated 
or trusted, that root store can be easily manipulated even by a 
software, even without locally manipulation the MitM can issue a 
certificate to the client by simply hijacking the connection and having 
certificate issued by trusted CA, and the client will validate and trust 
that certificate.


Again i am sorry that you feel i am raising an issue, i am not, only 
suggesting a concerning matter to discuss.


Best regards and sorry for wasting your time,
K. Obaideen
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

  *   My suggestion with something similar to DANE and DKIM (in utilizing DNS 
and DNSSEC), DNS TXT record is already been used by acme protocol to pass a 
challenge, so why not use similar implementation to authenticate the server 
itself for the client, so the client can verify the certificate and the chain, 
without a third-party.

No third-party is needed.  The client has to trust *something* out of band.  In 
a browser, this is typically the root store, and any CA trust chain should end 
up being signed by something in that store.  Other clients have different 
methods, but they are ultimately a set of trusted “root anchors.”  If you put 
data in DNS, then the client has to trust DNS and the chain that signed that 
data.

I think we’re struggling to understand the issue you are trying to raise.


___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/22/2018 7:14 PM, Salz, Rich wrote:


  * 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.

I am confused.  You are worried about an attacker “intercepting” the 
ACME connection and issuing a certificate to the client?


It is not necessary to add more “protection” at the TLS layer to 
protect against this.  The client can verify the signed certificate, 
and CA chain, that comes back.  DANE is not widely used, and it seems 
like a mistake to require it for ACME.



Hi Richard,

My suggestion with something similar to DANE and DKIM (in utilizing DNS 
and DNSSEC), DNS TXT record is already been used by acme protocol to 
pass a challenge, so why not use similar implementation to authenticate 
the server itself for the client, so the client can verify the 
certificate and the chain, without a third-party.
You are the expert editors and contributors here, it is your job will 
decide to do this on ACME protocol layer or TLS layer, in both case it 
should use DNS TXT record and stay away from waiting for DANE or 
depending on external resources.


Best regards,
K. Obaideen
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Kas]

On 10/22/2018 6:10 PM, Richard Barnes wrote:



On Mon, Oct 22, 2018 at 10:57 AM Kas > wrote:



On 10/22/2018 5:40 PM, Richard Barnes wrote:

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

Exactly, MitM can issue a certificate with his own SAN, so how to 
validate a chain properly without third party ? what if the MitM has 
issued to the client a certificate with known trusted CA by the system, 
against what should the client validate and verify such certificate and 
its chain ?


I don't see a way to verify a chain without third party ( trusted or 
known) as all root certificate are self-signed, how much time do you 
think is needed before changing this protocol to enforce DANE, DANE 
should be enforced long time ago but it will not happen any soon, and on 
other hand why repeat the process DKIM went through, till now it is not 
enforced but don't expect your email to reach its destination without 
proper DKIM.
My point is don't waste this opportunity to implement the protocol the 
right way, all what you need is something like those examples i wrote, 
and here another one :
in many server client application i wrote i used PSK ( pre-shared key) , 
server has a RSA public key in DNS TXT record and the client use it to 
encode his random generated pre-shared key and send it as hint to the 
server.


My intention is not wasting anyone time, just explaining a point that 
can be problem in the future, and i am sure all of you can reach the 
perfect solution.


Best regards
K. Obaideen





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
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 

Re: [Acme] Please consider adding server authentication

[Salz, Rich]

  *   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.

I am confused.  You are worried about an attacker “intercepting” the ACME 
connection and issuing a certificate to the client?
It is not necessary to add more “protection” at the TLS layer to protect 
against this.  The client can verify the signed certificate, and CA chain, that 
comes back.  DANE is not widely used, and it seems like a mistake to require it 
for ACME.

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

On Mon, Oct 22, 2018 at 10:57 AM Kas  wrote:

>
> On 10/22/2018 5:40 PM, Richard Barnes wrote:
>
> On Mon, Oct 22, 2018 at 10:13 AM Kas 
> 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 
>> 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 

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

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

Re: [Acme] Please consider adding server authentication

[Kas]

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 > 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

Re: [Acme] Please consider adding server authentication

[Richard Barnes]

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  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] Please consider adding server authentication

[Kas]

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