Re: [Acme] ALPN based TLS challenge

[Tim Hollebeek]

The concerns in this email, many of which I share, are the reason why I’d 
really like to get around to doing a full security analysis of all of the BR 
validation methods at some point.  They’ve mostly been considered in isolation, 
when in reality there are many overlapping themes.

 

Maybe we’ll at least make some progress towards a more unified and coherent 
understanding of validation tomorrow.

 

-Tim

 

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ryan Sleevi
Sent: Monday, February 26, 2018 2:09 PM
To: Doug Beattie <doug.beat...@globalsign.com>
Cc: IETF ACME <acme@ietf.org>; c...@letsencrypt.org
Subject: Re: [Acme] ALPN based TLS challenge

 

 

 

On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie <doug.beat...@globalsign.com 
<mailto:doug.beat...@globalsign.com> > wrote:

 

I would find it a bit surprising if the CABF adopted a domain validation method 
that relied on the web hosting provider claiming to do the right thing (to 
separate users on shared IP addresses so they cannot request certs from the 
other customers on that IP address). 

 

I'm surprised that it's seen as surprising, as this is already the implicit 
assumption for the validation methods within the CA/Browser Forum's Baseline 
Requirements.

 

Notable among the comparisons would be to 3.2.2.4.4, which makes a presumption 
that the email provider for the domain has not only observed RFC 2142 Section 
5, but also the CA/Browser Forum specific aliases of "admin" and "administrator"

 

Alternatively, one might consider the comparison to 3.2.2.4.6, in which the 
presumption is made that the /.well-known/ path is restricted from general 
access. Section 8.3 of ACME ( 
https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 ) specifically 
encourages the following of redirects when dereferencing the /.well-known/, but 
this understandably opens up attacks should a blanket redirect be used.

 

That said, I do think the artificial distinction between "web hosting provider" 
may be detrimental. Given the existing of the CA/Browser Forum's 3.2.2.4.8, one 
can equally see an attack made under such shared-hosting scenarios by any CA 
that utilizes the .8 methods of validation, in that multiple tenants on that IP 
would have access to respond for that IP (under 3.2.2.5)

 

Has anyone discussed this with the CABF?  I’d recommend that someone send this 
out to the public list for feedback.

 

Considering that the method described is consistent with 3.2.2.4.10 in the 
Baseline Requirements, did you mean to suggest conversations with Root Store 
programs that might otherwise restrict the usage of methods beyond that of the 
Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and .10 without 
specific mitigations?

 

As one such Root Store operator, we're happy to see this method progress within 
the IETF, and believe it provides suitable mitigations for the issues 
disclosed. In retrospect, the introduction of the TLS-SNI method as specified 
in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4 , is 
functionally no different than introducing a new e-mail alias in the 3.2.2.4.4 
method of validation - that is, presuming that all at-risk domains (such as 
those that allow arbitrary e-mail registration) must now take steps to block. 
The proposed method provides an opt-in, rather than an opt-out, and thus 
provides suitable mitigation.

 

Much like a domain holder could choose a hosting provider that permits 
arbitrary modification to /.well-known/ or arbitrary DNS modification, I do not 
believe this introduces any additional security holes compared to the 
presently-industry-accepted methods of validating domain control.

 

 

Doug

 

From: Acme [mailto:acme-boun...@ietf.org <mailto:acme-boun...@ietf.org> ] On 
Behalf Of Daniel McCarney
Sent: Monday, February 26, 2018 2:14 PM
Cc: IETF ACME <acme@ietf.org <mailto:acme@ietf.org> >
Subject: Re: [Acme] ALPN based TLS challenge

 

+1

The WG should adopt this document. I will volunteer to help review if adopted.

 

 

On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes <r...@ipv.sx 
<mailto:r...@ipv.sx> > wrote:

+1

 

This approach is a major improvement from earlier efforts at a TLS-based 
challenge.  It follows normal TLS processing logic much more closely, differing 
only in the fact that the certificate presented has an extra extension.  
Minimizing the differences w.r.t. normal behavior seems like a good approach to 
avoiding the sorts of corner cases that have tripped up earlier flavors of 
TLS-based challenges.

 

Before this is finalized as an RFC, we should verify empirically that most 
hosting providers will be secure in the presence of this challenge.  But I'm 
convinced that the approach in Roland's document is likely enough to work that 
we should go ahead and develop a specification, which we can test as it matures.

 

--Richard

 

 

On Fri, Feb 23

Re: [Acme] ALPN based TLS challenge

[Salz, Rich]

It’s good to see that there is a great deal of outside interest in this draft.

It would be *really way much better* if we first had the main document done.  
Folks involved in that, please don’t get distracted by this – there will be 
plenty of time later.  But first let’s get the main document in front of the 
IESG.

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

Re: [Acme] ALPN based TLS challenge

[Doug Beattie]

Hopefully the validation summit next week will lay out the assumptions on what 
needs to happen outside of the CAs’ control to properly perform domain 
validation.  Accurate technical descriptions of what’s needed for successful 
domain validation will help evaluate each method and we’ll be able to more 
clearly evaluate the risk, and you’ve hit several important points in your 
email.

While methods 9 and 10 are still in the BRs, I’ve written them off because the 
root programs have mandated mitigations to permit their temporary continued 
use.  It sounds like they may be updated to specify the mitigations, which is 
good – we need TLS based method.


From: Ryan Sleevi [mailto:ryan-i...@sleevi.com]
Sent: Monday, February 26, 2018 4:09 PM
To: Doug Beattie <doug.beat...@globalsign.com>
Cc: c...@letsencrypt.org; IETF ACME <acme@ietf.org>
Subject: Re: [Acme] ALPN based TLS challenge



On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie 
<doug.beat...@globalsign.com<mailto:doug.beat...@globalsign.com>> wrote:

I would find it a bit surprising if the CABF adopted a domain validation method 
that relied on the web hosting provider claiming to do the right thing (to 
separate users on shared IP addresses so they cannot request certs from the 
other customers on that IP address).

I'm surprised that it's seen as surprising, as this is already the implicit 
assumption for the validation methods within the CA/Browser Forum's Baseline 
Requirements.

Notable among the comparisons would be to 3.2.2.4.4, which makes a presumption 
that the email provider for the domain has not only observed RFC 2142 Section 
5, but also the CA/Browser Forum specific aliases of "admin" and "administrator"

Yes, that is true, but in this case the domain owner is protecting their 
domain.  The potential abuse of method 10 or 6 when servers that permit 
multiple customers on one IP address don’t implement the proper mitigations 
would open up any domain on shared IP address to improper domain validation.  
The discussions and comparisons of each method would likely highlight this as a 
smaller risk and one that the domain owner can mitigate themselves.

Alternatively, one might consider the comparison to 3.2.2.4.6, in which the 
presumption is made that the /.well-known/ path is restricted from general 
access. Section 8.3 of ACME ( 
https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 ) specifically 
encourages the following of redirects when dereferencing the /.well-known/, but 
this understandably opens up attacks should a blanket redirect be used.


That said, I do think the artificial distinction between "web hosting provider" 
may be detrimental. Given the existing of the CA/Browser Forum's 3.2.2.4.8, one 
can equally see an attack made under such shared-hosting scenarios by any CA 
that utilizes the .8 methods of validation, in that multiple tenants on that IP 
would have access to respond for that IP (under 3.2.2.5)

Agree, and you didn’t even bring up the “any other method” buried in .8 which 
is even worse.
Has anyone discussed this with the CABF?  I’d recommend that someone send this 
out to the public list for feedback.

Considering that the method described is consistent with 3.2.2.4.10 in the 
Baseline Requirements, did you mean to suggest conversations with Root Store 
programs that might otherwise restrict the usage of methods beyond that of the 
Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and .10 without 
specific mitigations?

Having a clear set of approved mitigations for these methods is necessary.  If 
ALPN is to be listed as an approved method and the mitigations are clearly 
called out in method 10 (or a new method), then it will be clear to everyone 
how they can be used. Right now it’s not at all clear how 9 and 10 can be used, 
other than to propose mitigation to the root programs for review, and even when 
that is done, the approvals seem to be temporary (LE to phase out all use of 
TLS-SNI-01).

Anyway, this is probably getting a bit off-topic for this list and we should 
bring it back to the CAB Public or Validation list where it belongs.


As one such Root Store operator, we're happy to see this method progress within 
the IETF, and believe it provides suitable mitigations for the issues 
disclosed. In retrospect, the introduction of the TLS-SNI method as specified 
in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4 , is 
functionally no different than introducing a new e-mail alias in the 3.2.2.4.4 
method of validation - that is, presuming that all at-risk domains (such as 
those that allow arbitrary e-mail registration) must now take steps to block. 
The proposed method provides an opt-in, rather than an opt-out, and thus 
provides suitable mitigation.

Much like a domain holder could choose a hosting provider that permits 
arbitrary modification to /.well-known/ or arbitrary DNS modification, I do not 
believe 

Re: [Acme] ALPN based TLS challenge

[Ryan Sleevi]

On Mon, Feb 26, 2018 at 3:33 PM, Doug Beattie <doug.beat...@globalsign.com>
wrote:

>
>
> I would find it a bit surprising if the CABF adopted a domain validation
> method that relied on the web hosting provider claiming to do the right
> thing (to separate users on shared IP addresses so they cannot request
> certs from the other customers on that IP address).
>

I'm surprised that it's seen as surprising, as this is already the implicit
assumption for the validation methods within the CA/Browser Forum's
Baseline Requirements.

Notable among the comparisons would be to 3.2.2.4.4, which makes a
presumption that the email provider for the domain has not only observed
RFC 2142 Section 5, but also the CA/Browser Forum specific aliases of
"admin" and "administrator"

Alternatively, one might consider the comparison to 3.2.2.4.6, in which the
presumption is made that the /.well-known/ path is restricted from general
access. Section 8.3 of ACME (
https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.3 )
specifically encourages the following of redirects when dereferencing the
/.well-known/, but this understandably opens up attacks should a blanket
redirect be used.

That said, I do think the artificial distinction between "web hosting
provider" may be detrimental. Given the existing of the CA/Browser Forum's
3.2.2.4.8, one can equally see an attack made under such shared-hosting
scenarios by any CA that utilizes the .8 methods of validation, in that
multiple tenants on that IP would have access to respond for that IP (under
3.2.2.5)


> Has anyone discussed this with the CABF?  I’d recommend that someone send
> this out to the public list for feedback.
>

Considering that the method described is consistent with 3.2.2.4.10 in the
Baseline Requirements, did you mean to suggest conversations with Root
Store programs that might otherwise restrict the usage of methods beyond
that of the Baseline Requirements, such as forbidding 3.2.2.4.1, .5, .9 and
.10 without specific mitigations?

As one such Root Store operator, we're happy to see this method progress
within the IETF, and believe it provides suitable mitigations for the
issues disclosed. In retrospect, the introduction of the TLS-SNI method as
specified in https://tools.ietf.org/html/draft-ietf-acme-acme-09#section-8.4
, is functionally no different than introducing a new e-mail alias in the
3.2.2.4.4 method of validation - that is, presuming that all at-risk
domains (such as those that allow arbitrary e-mail registration) must now
take steps to block. The proposed method provides an opt-in, rather than an
opt-out, and thus provides suitable mitigation.

Much like a domain holder could choose a hosting provider that permits
arbitrary modification to /.well-known/ or arbitrary DNS modification, I do
not believe this introduces any additional security holes compared to the
presently-industry-accepted methods of validating domain control.


>
>
> Doug
>
>
>
> *From:* Acme [mailto:acme-boun...@ietf.org] *On Behalf Of *Daniel McCarney
> *Sent:* Monday, February 26, 2018 2:14 PM
> *Cc:* IETF ACME <acme@ietf.org>
> *Subject:* Re: [Acme] ALPN based TLS challenge
>
>
>
> +1
>
> The WG should adopt this document. I will volunteer to help review if
> adopted.
>
>
>
>
>
> On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes <r...@ipv.sx> wrote:
>
> +1
>
>
>
> This approach is a major improvement from earlier efforts at a TLS-based
> challenge.  It follows normal TLS processing logic much more closely,
> differing only in the fact that the certificate presented has an extra
> extension.  Minimizing the differences w.r.t. normal behavior seems like a
> good approach to avoiding the sorts of corner cases that have tripped up
> earlier flavors of TLS-based challenges.
>
>
>
> Before this is finalized as an RFC, we should verify empirically that most
> hosting providers will be secure in the presence of this challenge.  But
> I'm convinced that the approach in Roland's document is likely enough to
> work that we should go ahead and develop a specification, which we can test
> as it matures.
>
>
>
> --Richard
>
>
>
>
>
> On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>
>
> On 23/02/18 16:31, Salz, Rich wrote:
> >
> >> Here is the ID:
> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> >
> > Should the WG adopt this document?
>
> Yes.
>
> Having a sufficiently secure mechanism that works on port 443 is
> a good thing in general. I'm not sure how many folks were using
> tls-sni-01 for new domains (I was) but whatever that number was,
> is I think evidence that a port 443 scheme fills a read need.
>
&

Re: [Acme] ALPN based TLS challenge

[Doug Beattie]

I would find it a bit surprising if the CABF adopted a domain validation method 
that relied on the web hosting provider claiming to do the right thing (to 
separate users on shared IP addresses so they cannot request certs from the 
other customers on that IP address).

Has anyone discussed this with the CABF?  I’d recommend that someone send this 
out to the public list for feedback.

Doug

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Daniel McCarney
Sent: Monday, February 26, 2018 2:14 PM
Cc: IETF ACME <acme@ietf.org>
Subject: Re: [Acme] ALPN based TLS challenge

+1

The WG should adopt this document. I will volunteer to help review if adopted.


On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes 
<r...@ipv.sx<mailto:r...@ipv.sx>> wrote:
+1

This approach is a major improvement from earlier efforts at a TLS-based 
challenge.  It follows normal TLS processing logic much more closely, differing 
only in the fact that the certificate presented has an extra extension.  
Minimizing the differences w.r.t. normal behavior seems like a good approach to 
avoiding the sorts of corner cases that have tripped up earlier flavors of 
TLS-based challenges.

Before this is finalized as an RFC, we should verify empirically that most 
hosting providers will be secure in the presence of this challenge.  But I'm 
convinced that the approach in Roland's document is likely enough to work that 
we should go ahead and develop a specification, which we can test as it matures.

--Richard


On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell 
<stephen.farr...@cs.tcd.ie<mailto:stephen.farr...@cs.tcd.ie>> wrote:


On 23/02/18 16:31, Salz, Rich wrote:
>
>> Here is the ID:
>> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
>
> Should the WG adopt this document?

Yes.

Having a sufficiently secure mechanism that works on port 443 is
a good thing in general. I'm not sure how many folks were using
tls-sni-01 for new domains (I was) but whatever that number was,
is I think evidence that a port 443 scheme fills a read need.

I assume that if problems are found with the new mechanism
(whether those be technical, due to odd deployments or I guess
even cabforum politics;-) then we'd recognise that and stop
the work. The fact that we did that to tls-sni-02 hould be
re-assuring wrt this.

If one accepts the two assertions above then adoption seems
like a no-brainer.

S.

> Speak up now, we'll make a
> consensus decision next week.  Also if you are able to help work on
> it.  If adopted, I would expect this to be on the agenda for London
> next month, even if it's just to briefly introduce it.
>
>
> ___ Acme mailing list
> Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
>
--
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

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


___
Acme mailing list
Acme@ietf.org<mailto: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] ALPN based TLS challenge

[Daniel McCarney]

+1

The WG should adopt this document. I will volunteer to help review if
adopted.


On Mon, Feb 26, 2018 at 12:02 PM, Richard Barnes  wrote:

> +1
>
> This approach is a major improvement from earlier efforts at a TLS-based
> challenge.  It follows normal TLS processing logic much more closely,
> differing only in the fact that the certificate presented has an extra
> extension.  Minimizing the differences w.r.t. normal behavior seems like a
> good approach to avoiding the sorts of corner cases that have tripped up
> earlier flavors of TLS-based challenges.
>
> Before this is finalized as an RFC, we should verify empirically that most
> hosting providers will be secure in the presence of this challenge.  But
> I'm convinced that the approach in Roland's document is likely enough to
> work that we should go ahead and develop a specification, which we can test
> as it matures.
>
> --Richard
>
>
> On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell <
> stephen.farr...@cs.tcd.ie> wrote:
>
>>
>>
>> On 23/02/18 16:31, Salz, Rich wrote:
>> >
>> >> Here is the ID:
>> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
>> >
>> > Should the WG adopt this document?
>>
>> Yes.
>>
>> Having a sufficiently secure mechanism that works on port 443 is
>> a good thing in general. I'm not sure how many folks were using
>> tls-sni-01 for new domains (I was) but whatever that number was,
>> is I think evidence that a port 443 scheme fills a read need.
>>
>> I assume that if problems are found with the new mechanism
>> (whether those be technical, due to odd deployments or I guess
>> even cabforum politics;-) then we'd recognise that and stop
>> the work. The fact that we did that to tls-sni-02 hould be
>> re-assuring wrt this.
>>
>> If one accepts the two assertions above then adoption seems
>> like a no-brainer.
>>
>> S.
>>
>> > Speak up now, we'll make a
>> > consensus decision next week.  Also if you are able to help work on
>> > it.  If adopted, I would expect this to be on the agenda for London
>> > next month, even if it's just to briefly introduce it.
>> >
>> >
>> > ___ Acme mailing list
>> > Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
>> >
>>
>> --
>> PGP key change time for me.
>> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
>> NewWithOld sigs in keyservers.
>> Sorry if that mucks something up;-)
>>
>> ___
>> 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

Re: [Acme] ALPN based TLS challenge

[Richard Barnes]

+1

This approach is a major improvement from earlier efforts at a TLS-based
challenge.  It follows normal TLS processing logic much more closely,
differing only in the fact that the certificate presented has an extra
extension.  Minimizing the differences w.r.t. normal behavior seems like a
good approach to avoiding the sorts of corner cases that have tripped up
earlier flavors of TLS-based challenges.

Before this is finalized as an RFC, we should verify empirically that most
hosting providers will be secure in the presence of this challenge.  But
I'm convinced that the approach in Roland's document is likely enough to
work that we should go ahead and develop a specification, which we can test
as it matures.

--Richard


On Fri, Feb 23, 2018 at 11:41 AM, Stephen Farrell  wrote:

>
>
> On 23/02/18 16:31, Salz, Rich wrote:
> >
> >> Here is the ID:
> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> >
> > Should the WG adopt this document?
>
> Yes.
>
> Having a sufficiently secure mechanism that works on port 443 is
> a good thing in general. I'm not sure how many folks were using
> tls-sni-01 for new domains (I was) but whatever that number was,
> is I think evidence that a port 443 scheme fills a read need.
>
> I assume that if problems are found with the new mechanism
> (whether those be technical, due to odd deployments or I guess
> even cabforum politics;-) then we'd recognise that and stop
> the work. The fact that we did that to tls-sni-02 hould be
> re-assuring wrt this.
>
> If one accepts the two assertions above then adoption seems
> like a no-brainer.
>
> S.
>
> > Speak up now, we'll make a
> > consensus decision next week.  Also if you are able to help work on
> > it.  If adopted, I would expect this to be on the agenda for London
> > next month, even if it's just to briefly introduce it.
> >
> >
> > ___ Acme mailing list
> > Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
> >
>
> --
> PGP key change time for me.
> New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
> NewWithOld sigs in keyservers.
> Sorry if that mucks something up;-)
>
> ___
> 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] ALPN based TLS challenge

[Roland Bracewell Shoemaker]

I’ll be at the meeting in London and would be happy to give a quick 
introduction/overview of the method if adopted.

> On Feb 23, 2018, at 8:31 AM, Salz, Rich  wrote:
> 
> 
>>   Here is the ID: 
>> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> 
> Should the WG adopt this document?  Speak up now, we'll make a consensus 
> decision next week.  Also if you are able to help work on it.  If adopted, I 
> would expect this to be on the agenda for London next month, even if it's 
> just to briefly introduce it.
> 
> 

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

Re: [Acme] ALPN based TLS challenge

[Ilari Liusvaara]

On Fri, Feb 23, 2018 at 04:41:20PM +, Stephen Farrell wrote:
> 
> 
> On 23/02/18 16:31, Salz, Rich wrote:
> > 
> >> Here is the ID:
> >> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> > 
> > Should the WG adopt this document?  
> 
> Yes.
> 
> Having a sufficiently secure mechanism that works on port 443 is
> a good thing in general. I'm not sure how many folks were using
> tls-sni-01 for new domains (I was) but whatever that number was,
> is I think evidence that a port 443 scheme fills a read need.

Having port 443 scheme is handy if you have a webserver with
built in support for ACME (not having to mess with either port
80 or DNS for validation).

Apparently there are some users that are unwilling or unable to
open port 80. And DNS is hit or miss depending on provoder.
 

> I assume that if problems are found with the new mechanism
> (whether those be technical, due to odd deployments or I guess
> even cabforum politics;-) then we'd recognise that and stop
> the work. The fact that we did that to tls-sni-02 hould be
> re-assuring wrt this.

I think virtually all of the CABForum issues are associated
with being sceptical about security of schemes like this.


-Ilari

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

Re: [Acme] ALPN based TLS challenge [invalid signature!]

[Ilari Liusvaara]

On Fri, Feb 23, 2018 at 03:04:46PM +, Doug Beattie wrote:
> 
> Oh yes, right.  The scope of attack is only those domains that point to the
> same IP address.  But, this still relies on web hosting companies to have
> secure configurations such that User A can’t get a cert for user B's domain
> when they share the same IP address.
> 
> As a CA I like this and would be able to get method 9 added back,  but it
> still has a dependency that the web hosting company is doing the right
> thing, and that might be a concern (we'd be depending on a web server
> configuration to enforce accurate domain validation).

Assuming that:

- The hosting provoder has dependent HTTP and HTTPS (most do).
- The hosting provoder supports sharing IP addresses between customers
  with HTTPS enabled, or maps each customer to dedicated address (AFAIK,
  all nowadays do either of these).
- The hosting provoder is not vulernable to unauthorized certificate
  replacements (which is fundamentally exploitable for Denial of
  Service).

Then this mechanism is secure against misvalidation. These two
conditions are not sufficient for TLS-SNI-0x, because this method
also requires assumption that the attacker can not claim arbitrary
names.


However, there are some provoders with indepedent HTTP and HTTPS. For
example, the first provoder from the TLS-SNI misvalidation blogpost
(which was not identified, and has probably fixed this already). Names
hosted by these provoders can be attacked if the legimate owner does
not have HTTPS set up.

Specifically: Claim the name and then just validate it using some
method related to HTTPS, the hosting provoder thinks it is yours.
One can notice that the definition of method 6 has no provisions to
not be vulernable in such context (method 6 is also vulernable to
misvalidation if the victim has set up HTTPS but not HTTP).


-Ilari

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

Re: [Acme] ALPN based TLS challenge

[Stephen Farrell]

On 23/02/18 16:31, Salz, Rich wrote:
> 
>> Here is the ID:
>> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
> 
> Should the WG adopt this document?  

Yes.

Having a sufficiently secure mechanism that works on port 443 is
a good thing in general. I'm not sure how many folks were using
tls-sni-01 for new domains (I was) but whatever that number was,
is I think evidence that a port 443 scheme fills a read need.

I assume that if problems are found with the new mechanism
(whether those be technical, due to odd deployments or I guess
even cabforum politics;-) then we'd recognise that and stop
the work. The fact that we did that to tls-sni-02 hould be
re-assuring wrt this.

If one accepts the two assertions above then adoption seems
like a no-brainer.

S.

> Speak up now, we'll make a
> consensus decision next week.  Also if you are able to help work on
> it.  If adopted, I would expect this to be on the agenda for London
> next month, even if it's just to briefly introduce it.
> 
> 
> ___ Acme mailing list 
> Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
> 

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)


0x7B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ALPN based TLS challenge

[Salz, Rich]

>Here is the ID: 
> https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/
  
Should the WG adopt this document?  Speak up now, we'll make a consensus 
decision next week.  Also if you are able to help work on it.  If adopted, I 
would expect this to be on the agenda for London next month, even if it's just 
to briefly introduce it.


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

Re: [Acme] ALPN based TLS challenge [invalid signature!] [invalid signature!]

[Sebastian Nielsen]

Exactly. But its also not the CA's responsibility if web host companies are 
insecure. Customers choosing insecure hosting companies and then having certs 
issued for their domains by attackers, have themselves to blame.
The problem was that web hosting companies were unaware about the SNI 
validation method, thus it was really not the customer's or webhost's fault. 
With ALPN, they have indicated "Yes we are aware about the security 
consequences for our customers. Lets continue anyways".
Then it's not really the CA's problem anymore, the CA has done everything in 
its power to ensure security.
 Originalmeddelande Från: Doug Beattie 
<doug.beat...@globalsign.com> Datum: 2018-02-23  16:04  (GMT+01:00) Till: 
Sebastian Nielsen <sebast...@sebbe.eu>, 'Roland Bracewell Shoemaker' 
<rol...@letsencrypt.org>, 'Rich Salz' <rs...@akamai.com> Kopia: 'IETF ACME' 
<acme@ietf.org>, 'Martin Thomson' <martin.thom...@gmail.com> Rubrik: RE: [Acme] 
ALPN based TLS challenge [invalid signature!] [invalid
  signature!] 

Oh yes, right.  The scope of attack is only those domains that point to the
same IP address.  But, this still relies on web hosting companies to have
secure configurations such that User A can’t get a cert for user B's domain
when they share the same IP address.

As a CA I like this and would be able to get method 9 added back,  but it
still has a dependency that the web hosting company is doing the right
thing, and that might be a concern (we'd be depending on a web server
configuration to enforce accurate domain validation).

If this has the endorsement of Google and Mozilla, I'm in for it also.

Doug

> -Original Message-
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:48 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Subject: SV: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Yes. The domain validated must still point to the correct server. This is
> true for both the old TLS-SNI-01 validation and the new ALPN validation.
> 
> -Ursprungligt meddelande-
> Från: Doug Beattie [mailto:doug.beat...@globalsign.com]
> Skickat: den 23 februari 2018 15:47
> Till: Sebastian Nielsen <sebast...@sebbe.eu>; 'Roland Bracewell Shoemaker'
> <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Kopia: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Ämne: RE: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Does this prevent an advisory from setting up their own "hosting provider"
> and getting certificates for any domain on the internet?  We can’t assume
> all landlords are good.
> 
> Doug
> 
> > -Original Message-
> > From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> > Sent: Friday, February 23, 2018 9:43 AM
> > To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> > Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> > Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> > <martin.thom...@gmail.com>
> > Subject: SV: [Acme] ALPN based TLS challenge
> >
> > The problem was that there was hosting providers which did not know that
> the
> > SNI would be used in validation,
> > and did not limit or restrict which SNI names a customer could set up
> > content for, to the domain names that the customer had proofed ownership
> > of.
> >
> > The new ALPN based challenge, requires the server to explicitly say it
do
> > support validation, thus it means a hosting provider needs explicit
> > configuration of the TLS parameters to enable Lets Encrypt validation,
> thus
> > the risk that a hosting provider unknowingly allows a adversiary to
> > authenticate as a another customer on the same hosting platform is
> > eliminated.
> >
> > There is still the risk that a hosting provider explicitly sets up a
> server
> > which annouces support for TLS validation in ALPN, and still do allow
> > third-parties to set up validations for arbitary domain names.
> >
> > But then the error is on that hosting provider. Remember that the
security
> > issue ONLY appears if both the customer (which has legiitmate access to
a
> > domain) and the adversiary is on the same hosting provider, and in most
> > cases, even the same server.
> >
> > Thus there is the responsibility of the real customer to move away from
> any
> > hosting provider that have a explicit configuration that 

Re: [Acme] ALPN based TLS challenge [invalid signature!]

[Doug Beattie]

Oh yes, right.  The scope of attack is only those domains that point to the
same IP address.  But, this still relies on web hosting companies to have
secure configurations such that User A can’t get a cert for user B's domain
when they share the same IP address.

As a CA I like this and would be able to get method 9 added back,  but it
still has a dependency that the web hosting company is doing the right
thing, and that might be a concern (we'd be depending on a web server
configuration to enforce accurate domain validation).

If this has the endorsement of Google and Mozilla, I'm in for it also.

Doug

> -Original Message-
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:48 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Subject: SV: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Yes. The domain validated must still point to the correct server. This is
> true for both the old TLS-SNI-01 validation and the new ALPN validation.
> 
> -Ursprungligt meddelande-
> Från: Doug Beattie [mailto:doug.beat...@globalsign.com]
> Skickat: den 23 februari 2018 15:47
> Till: Sebastian Nielsen <sebast...@sebbe.eu>; 'Roland Bracewell Shoemaker'
> <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Kopia: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Ämne: RE: [Acme] ALPN based TLS challenge [invalid signature!]
> 
> Does this prevent an advisory from setting up their own "hosting provider"
> and getting certificates for any domain on the internet?  We can’t assume
> all landlords are good.
> 
> Doug
> 
> > -Original Message-
> > From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> > Sent: Friday, February 23, 2018 9:43 AM
> > To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> > Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> > Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> > <martin.thom...@gmail.com>
> > Subject: SV: [Acme] ALPN based TLS challenge
> >
> > The problem was that there was hosting providers which did not know that
> the
> > SNI would be used in validation,
> > and did not limit or restrict which SNI names a customer could set up
> > content for, to the domain names that the customer had proofed ownership
> > of.
> >
> > The new ALPN based challenge, requires the server to explicitly say it
do
> > support validation, thus it means a hosting provider needs explicit
> > configuration of the TLS parameters to enable Lets Encrypt validation,
> thus
> > the risk that a hosting provider unknowingly allows a adversiary to
> > authenticate as a another customer on the same hosting platform is
> > eliminated.
> >
> > There is still the risk that a hosting provider explicitly sets up a
> server
> > which annouces support for TLS validation in ALPN, and still do allow
> > third-parties to set up validations for arbitary domain names.
> >
> > But then the error is on that hosting provider. Remember that the
security
> > issue ONLY appears if both the customer (which has legiitmate access to
a
> > domain) and the adversiary is on the same hosting provider, and in most
> > cases, even the same server.
> >
> > Thus there is the responsibility of the real customer to move away from
> any
> > hosting provider that have a explicit configuration that would allow a
> > adversiary to validate as that customer with ALPN enabled.
> >
> >
> > To make a analog comparisation:
> > Imagine a house with 4 apartments. Normally, each apartment should be
> > separate. But there is old houses with doors between apartments that are
> not
> > locked. A delivery guy comes with a package containing sensitive things,
> and
> > the delivery guy simply checks that the person receiving the package can
> > exit out of the correct apartment door.
> >
> > Due to the security risk in the house with the unlocked door between
each
> > apartment, any tenant can exit out of any apartment door, and thus
receive
> > the package, creating a security risk if a evil adversiary hires one of
> the
> > apartments.
> >
> > The ALPN challenge, is equvalient with a new sign the landlord can set
up
> on
> > the doors, that these apartments are "Secure". The delivery guy will
only
> > deliver to apartments that have a "Sec

Re: [Acme] ALPN based TLS challenge [invalid signature!]

[Sebastian Nielsen]

Yes. The domain validated must still point to the correct server. This is
true for both the old TLS-SNI-01 validation and the new ALPN validation.

-Ursprungligt meddelande-
Från: Doug Beattie [mailto:doug.beat...@globalsign.com] 
Skickat: den 23 februari 2018 15:47
Till: Sebastian Nielsen <sebast...@sebbe.eu>; 'Roland Bracewell Shoemaker'
<rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
Kopia: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
<martin.thom...@gmail.com>
Ämne: RE: [Acme] ALPN based TLS challenge [invalid signature!]

Does this prevent an advisory from setting up their own "hosting provider"
and getting certificates for any domain on the internet?  We can’t assume
all landlords are good.

Doug

> -Original Message-
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:43 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Subject: SV: [Acme] ALPN based TLS challenge
> 
> The problem was that there was hosting providers which did not know that
the
> SNI would be used in validation,
> and did not limit or restrict which SNI names a customer could set up
> content for, to the domain names that the customer had proofed ownership
> of.
> 
> The new ALPN based challenge, requires the server to explicitly say it do
> support validation, thus it means a hosting provider needs explicit
> configuration of the TLS parameters to enable Lets Encrypt validation,
thus
> the risk that a hosting provider unknowingly allows a adversiary to
> authenticate as a another customer on the same hosting platform is
> eliminated.
> 
> There is still the risk that a hosting provider explicitly sets up a
server
> which annouces support for TLS validation in ALPN, and still do allow
> third-parties to set up validations for arbitary domain names.
> 
> But then the error is on that hosting provider. Remember that the security
> issue ONLY appears if both the customer (which has legiitmate access to a
> domain) and the adversiary is on the same hosting provider, and in most
> cases, even the same server.
> 
> Thus there is the responsibility of the real customer to move away from
any
> hosting provider that have a explicit configuration that would allow a
> adversiary to validate as that customer with ALPN enabled.
> 
> 
> To make a analog comparisation:
> Imagine a house with 4 apartments. Normally, each apartment should be
> separate. But there is old houses with doors between apartments that are
not
> locked. A delivery guy comes with a package containing sensitive things,
and
> the delivery guy simply checks that the person receiving the package can
> exit out of the correct apartment door.
> 
> Due to the security risk in the house with the unlocked door between each
> apartment, any tenant can exit out of any apartment door, and thus receive
> the package, creating a security risk if a evil adversiary hires one of
the
> apartments.
> 
> The ALPN challenge, is equvalient with a new sign the landlord can set up
on
> the doors, that these apartments are "Secure". The delivery guy will only
> deliver to apartments that have a "Secure" sign. Thus the old apartments
> lacking doors between the apartments will then not have any "Secure" sign.
> Yes, the landlord can set up a "Secure" sign even on insecure apartments,
> but thats an explicit action, and the passive security risk is eliminated,
> which means that if the landlord sets up the "Secure" sign on insecure
> apartments, its the responsibility of the tenant to move away from there.
> 
> You understand now?
> 
> -Ursprungligt meddelande-
> Från: Acme [mailto:acme-boun...@ietf.org] För Doug Beattie
> Skickat: den 23 februari 2018 14:18
> Till: Roland Bracewell Shoemaker <rol...@letsencrypt.org>; Rich Salz
> <rs...@akamai.com>
> Kopia: IETF ACME <acme@ietf.org>; Martin Thomson
> <martin.thom...@gmail.com>
> Ämne: Re: [Acme] ALPN based TLS challenge
> 
> I'm probably not understanding a key piece of technical info about the
> protocol, but when I see this statement it makes me think it has similar
> issues to tls-sni-01.  If we're relying on the hosting provider enforcing
> certain constraints like this, then we're delegating a critical piece of
> domain control back to the hosting provider which would be a no-go.
> 
> 4.  Security Considerations
> 
>The design of this challenges relies on some assumptions centered
>around how a server behaves during validat

Re: [Acme] ALPN based TLS challenge

[Doug Beattie]

Does this prevent an advisory from setting up their own "hosting provider"
and getting certificates for any domain on the internet?  We can’t assume
all landlords are good.

Doug

> -Original Message-
> From: Sebastian Nielsen [mailto:sebast...@sebbe.eu]
> Sent: Friday, February 23, 2018 9:43 AM
> To: Doug Beattie <doug.beat...@globalsign.com>; 'Roland Bracewell
> Shoemaker' <rol...@letsencrypt.org>; 'Rich Salz' <rs...@akamai.com>
> Cc: 'IETF ACME' <acme@ietf.org>; 'Martin Thomson'
> <martin.thom...@gmail.com>
> Subject: SV: [Acme] ALPN based TLS challenge
> 
> The problem was that there was hosting providers which did not know that
the
> SNI would be used in validation,
> and did not limit or restrict which SNI names a customer could set up
> content for, to the domain names that the customer had proofed ownership
> of.
> 
> The new ALPN based challenge, requires the server to explicitly say it do
> support validation, thus it means a hosting provider needs explicit
> configuration of the TLS parameters to enable Lets Encrypt validation,
thus
> the risk that a hosting provider unknowingly allows a adversiary to
> authenticate as a another customer on the same hosting platform is
> eliminated.
> 
> There is still the risk that a hosting provider explicitly sets up a
server
> which annouces support for TLS validation in ALPN, and still do allow
> third-parties to set up validations for arbitary domain names.
> 
> But then the error is on that hosting provider. Remember that the security
> issue ONLY appears if both the customer (which has legiitmate access to a
> domain) and the adversiary is on the same hosting provider, and in most
> cases, even the same server.
> 
> Thus there is the responsibility of the real customer to move away from
any
> hosting provider that have a explicit configuration that would allow a
> adversiary to validate as that customer with ALPN enabled.
> 
> 
> To make a analog comparisation:
> Imagine a house with 4 apartments. Normally, each apartment should be
> separate. But there is old houses with doors between apartments that are
not
> locked. A delivery guy comes with a package containing sensitive things,
and
> the delivery guy simply checks that the person receiving the package can
> exit out of the correct apartment door.
> 
> Due to the security risk in the house with the unlocked door between each
> apartment, any tenant can exit out of any apartment door, and thus receive
> the package, creating a security risk if a evil adversiary hires one of
the
> apartments.
> 
> The ALPN challenge, is equvalient with a new sign the landlord can set up
on
> the doors, that these apartments are "Secure". The delivery guy will only
> deliver to apartments that have a "Secure" sign. Thus the old apartments
> lacking doors between the apartments will then not have any "Secure" sign.
> Yes, the landlord can set up a "Secure" sign even on insecure apartments,
> but thats an explicit action, and the passive security risk is eliminated,
> which means that if the landlord sets up the "Secure" sign on insecure
> apartments, its the responsibility of the tenant to move away from there.
> 
> You understand now?
> 
> -Ursprungligt meddelande-
> Från: Acme [mailto:acme-boun...@ietf.org] För Doug Beattie
> Skickat: den 23 februari 2018 14:18
> Till: Roland Bracewell Shoemaker <rol...@letsencrypt.org>; Rich Salz
> <rs...@akamai.com>
> Kopia: IETF ACME <acme@ietf.org>; Martin Thomson
> <martin.thom...@gmail.com>
> Ämne: Re: [Acme] ALPN based TLS challenge
> 
> I'm probably not understanding a key piece of technical info about the
> protocol, but when I see this statement it makes me think it has similar
> issues to tls-sni-01.  If we're relying on the hosting provider enforcing
> certain constraints like this, then we're delegating a critical piece of
> domain control back to the hosting provider which would be a no-go.
> 
> 4.  Security Considerations
> 
>The design of this challenges relies on some assumptions centered
>around how a server behaves during validation.
> 
>The first assumption is that when a server is being used to serve
>content for multiple DNS names from a single IP address that it
>properly segregates control of those names to the users on the server
>that own them.  This means that if User A registers Host A and User B
>registers Host B the server should not allow a TLS request using a
>SNI value for Host A that only User A should be able to serve that
>request.  If the server allows User B to serve this request it allows
>them to illegitimately validate

Re: [Acme] ALPN based TLS challenge

[Sebastian Nielsen]

The problem was that there was hosting providers which did not know that the
SNI would be used in validation,
and did not limit or restrict which SNI names a customer could set up
content for, to the domain names that the customer had proofed ownership of.

The new ALPN based challenge, requires the server to explicitly say it do
support validation, thus it means a hosting provider needs explicit
configuration of the TLS parameters to enable Lets Encrypt validation, thus
the risk that a hosting provider unknowingly allows a adversiary to
authenticate as a another customer on the same hosting platform is
eliminated.

There is still the risk that a hosting provider explicitly sets up a server
which annouces support for TLS validation in ALPN, and still do allow
third-parties to set up validations for arbitary domain names.

But then the error is on that hosting provider. Remember that the security
issue ONLY appears if both the customer (which has legiitmate access to a
domain) and the adversiary is on the same hosting provider, and in most
cases, even the same server.

Thus there is the responsibility of the real customer to move away from any
hosting provider that have a explicit configuration that would allow a
adversiary to validate as that customer with ALPN enabled.


To make a analog comparisation:
Imagine a house with 4 apartments. Normally, each apartment should be
separate. But there is old houses with doors between apartments that are not
locked. A delivery guy comes with a package containing sensitive things, and
the delivery guy simply checks that the person receiving the package can
exit out of the correct apartment door.

Due to the security risk in the house with the unlocked door between each
apartment, any tenant can exit out of any apartment door, and thus receive
the package, creating a security risk if a evil adversiary hires one of the
apartments.

The ALPN challenge, is equvalient with a new sign the landlord can set up on
the doors, that these apartments are "Secure". The delivery guy will only
deliver to apartments that have a "Secure" sign. Thus the old apartments
lacking doors between the apartments will then not have any "Secure" sign.
Yes, the landlord can set up a "Secure" sign even on insecure apartments,
but thats an explicit action, and the passive security risk is eliminated,
which means that if the landlord sets up the "Secure" sign on insecure
apartments, its the responsibility of the tenant to move away from there.

You understand now?

-Ursprungligt meddelande-
Från: Acme [mailto:acme-boun...@ietf.org] För Doug Beattie
Skickat: den 23 februari 2018 14:18
Till: Roland Bracewell Shoemaker <rol...@letsencrypt.org>; Rich Salz
<rs...@akamai.com>
Kopia: IETF ACME <acme@ietf.org>; Martin Thomson <martin.thom...@gmail.com>
Ämne: Re: [Acme] ALPN based TLS challenge

I'm probably not understanding a key piece of technical info about the
protocol, but when I see this statement it makes me think it has similar
issues to tls-sni-01.  If we're relying on the hosting provider enforcing
certain constraints like this, then we're delegating a critical piece of
domain control back to the hosting provider which would be a no-go.

4.  Security Considerations

   The design of this challenges relies on some assumptions centered
   around how a server behaves during validation.

   The first assumption is that when a server is being used to serve
   content for multiple DNS names from a single IP address that it
   properly segregates control of those names to the users on the server
   that own them.  This means that if User A registers Host A and User B
   registers Host B the server should not allow a TLS request using a
   SNI value for Host A that only User A should be able to serve that
   request.  If the server allows User B to serve this request it allows
   them to illegitimately validate control of Host A to the ACME server.

Please let me know what I'm missing.

Doug

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Roland Bracewell
> Shoemaker
> Sent: Friday, February 23, 2018 3:00 AM
> To: Rich Salz <rs...@akamai.com>
> Cc: IETF ACME <acme@ietf.org>; Martin Thomson
> <martin.thom...@gmail.com>
> Subject: Re: [Acme] ALPN based TLS challenge
> 
> Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-
> alpn/
> 
> > On Feb 22, 2018, at 8:38 PM, Salz, Rich <rs...@akamai.com> wrote:
> >
> > Yes, like Martin said, submit the individual draft and we can call for
adoption.
> >
> 
> ___
> 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



smime.p7s
Description: S/MIME Cryptographic Signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] ALPN based TLS challenge

[Ilari Liusvaara]

On Fri, Feb 23, 2018 at 01:17:53PM +, Doug Beattie wrote:
> I'm probably not understanding a key piece of technical info about the
> protocol, but when I see this statement it makes me think it has similar
> issues to tls-sni-01.  If we're relying on the hosting provider enforcing
> certain constraints like this, then we're delegating a critical piece of
> domain control back to the hosting provider which would be a no-go.
> 
> 4.  Security Considerations
> 
>The design of this challenges relies on some assumptions centered
>around how a server behaves during validation.
> 
>The first assumption is that when a server is being used to serve
>content for multiple DNS names from a single IP address that it
>properly segregates control of those names to the users on the server
>that own them.  This means that if User A registers Host A and User B
>registers Host B the server should not allow a TLS request using a
>SNI value for Host A that only User A should be able to serve that
>request.  If the server allows User B to serve this request it allows
>them to illegitimately validate control of Host A to the ACME server.
> 
> Please let me know what I'm missing.

The assumption that users can only influence HTTPS names they own
probably holds in practice. The entiere security of entiere methods 9
and 10 relies on exactly that. Exploiting TLS-SNI-0x did not require
answering for the name in question.

What I am more worried about is hosting providers which treat HTTP
and HTTPS independent from each other. These are not common, but there
are some. And judging from Globalsign ("oneclick") issue, either these
hosting provoders are relevant, or everyone just misunderstood the
issue. 


-Ilari

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

Re: [Acme] ALPN based TLS challenge

[Doug Beattie]

I'm probably not understanding a key piece of technical info about the 
protocol, but when I see this statement it makes me think it has similar issues 
to tls-sni-01.  If we're relying on the hosting provider enforcing certain 
constraints like this, then we're delegating a critical piece of domain control 
back to the hosting provider which would be a no-go.

4.  Security Considerations

   The design of this challenges relies on some assumptions centered
   around how a server behaves during validation.

   The first assumption is that when a server is being used to serve
   content for multiple DNS names from a single IP address that it
   properly segregates control of those names to the users on the server
   that own them.  This means that if User A registers Host A and User B
   registers Host B the server should not allow a TLS request using a
   SNI value for Host A that only User A should be able to serve that
   request.  If the server allows User B to serve this request it allows
   them to illegitimately validate control of Host A to the ACME server.

Please let me know what I'm missing.

Doug

> -Original Message-
> From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Roland Bracewell
> Shoemaker
> Sent: Friday, February 23, 2018 3:00 AM
> To: Rich Salz <rs...@akamai.com>
> Cc: IETF ACME <acme@ietf.org>; Martin Thomson
> <martin.thom...@gmail.com>
> Subject: Re: [Acme] ALPN based TLS challenge
> 
> Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-
> alpn/
> 
> > On Feb 22, 2018, at 8:38 PM, Salz, Rich <rs...@akamai.com> wrote:
> >
> > Yes, like Martin said, submit the individual draft and we can call for 
> > adoption.
> >
> 
> ___
> 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] ALPN based TLS challenge

[Roland Bracewell Shoemaker]

Here is the ID: https://datatracker.ietf.org/doc/draft-shoemaker-acme-tls-alpn/

> On Feb 22, 2018, at 8:38 PM, Salz, Rich  wrote:
> 
> Yes, like Martin said, submit the individual draft and we can call for 
> adoption.
> 

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

Re: [Acme] ALPN based TLS challenge

[Ilari Liusvaara]

On Thu, Feb 22, 2018 at 05:48:23PM -0800, Roland Bracewell Shoemaker wrote:
> Hey all,
> 
> After the issues with the SNI based TLS challenges were discovered
> there was interest from a number of parties in developing another
> challenge that did validation at the TLS layer. After some discussion
>  about possibilities we’ve come up with a new challenge type based on
> ALPN which we believe provides the required security properties which
> the SNI based methods did not have.
> 
> I’ve attached the rough draft of a document which defines this new
> method and lays out the security considerations and design rationale
> for it. 
> 
> Happy to field any questions about the details. 

If some hoster has indepent HTTP and HTTPS (some do) and such hoster
supports validating user certificates with this method, one can
hijack some HTTP name that does not have corresponding HTTPS name
(thanks to HSTS, and cookies are a lesser problem). Concerns about
such hosters were behind deprecating one GlobalSign validation method
involving test certificates (or else it was completely misunderstanding
the issue). However, even the HTTP validation method has issues with
hosters like this (there are problems also in other direction).

Also, this seems to aim for compliance for random value in certificate,
which I do not necressarily think is a good idea considering the amount
of issues with that method as described[1].


And as for implementability, this does look like something I could
implement in my TLS library (where requirement is to be able to
identify validation requests during ClientHello processing, and
validation request preferably not introducing new TLS messages[2]).
This method is identifiable such and does not introduce new TLS
messages.


[1] I have absolutely no reason to believe that issues with the
troublesome GlobalSign method where not due to fundamential
vulernabilities in the CABForum method they used. The random
value in certificate method has all the same concerns (plus
at least one bug unique to it... Fortunately this proposal
does not depend on that bug in any way).

[2] The latter is not hard constraint, it is just to avoid
having to write the pretty sizable chunk of code required to
alter the handshake state machine. The former is hard
constraint.


-Ilari

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

Re: [Acme] ALPN based TLS challenge

[Salz, Rich]

Yes, like Martin said, submit the individual draft and we can call for adoption.

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

Re: [Acme] ALPN based TLS challenge

[Martin Thomson]

Now is probably the time to publish in internet-draft form:
https://datatracker.ietf.org/submit/

On Fri, Feb 23, 2018 at 12:48 PM, Roland Bracewell Shoemaker
 wrote:
> Hey all,
>
> After the issues with the SNI based TLS challenges were discovered there was 
> interest from a number of parties in developing another challenge that did 
> validation at the TLS layer. After some discussion about possibilities we’ve 
> come up with a new challenge type based on ALPN which we believe provides the 
> required security properties which the SNI based methods did not have.
>
> I’ve attached the rough draft of a document which defines this new method and 
> lays out the security considerations and design rationale for it. Given the 
> interest in getting a new TLS method specified would the WG chairs be 
> amenable to directly adopting this as a WG work product (assuming there is 
> consensus on list) so that we can start work on it or is it required to be 
> submitted as a individual draft first?
>
> Happy to field any questions about the details. I’d also like to thank 
> everyone who provided initial input and editorial opinions on this.
>
> Thanks,
> Roland
>
>
> ___
> 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] ALPN based TLS challenge

[Roland Bracewell Shoemaker]

Hey all,

After the issues with the SNI based TLS challenges were discovered there was 
interest from a number of parties in developing another challenge that did 
validation at the TLS layer. After some discussion about possibilities we’ve 
come up with a new challenge type based on ALPN which we believe provides the 
required security properties which the SNI based methods did not have.

I’ve attached the rough draft of a document which defines this new method and 
lays out the security considerations and design rationale for it. Given the 
interest in getting a new TLS method specified would the WG chairs be amenable 
to directly adopting this as a WG work product (assuming there is consensus on 
list) so that we can start work on it or is it required to be submitted as a 
individual draft first?

Happy to field any questions about the details. I’d also like to thank everyone 
who provided initial input and editorial opinions on this.

Thanks,
Roland

# Introduction

The Automatic Certificate Management Environment (ACME) {{I-D.ietf-acme-acme}} specification doesn't specify a TLS layer validation method which limits the points at which validation can be performed. This document extends the ACME specification to include a TLS based validation method that uses the Application Level Protocol Negotiation extension.

# Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be
interpreted as described in BCP 14, RFC 2119 {{RFC2119}}.

# TLS with Application Level Protocol Negotiation (TLS ALPN) Challenge

The TLS with Application Level Protocol Negotiation (TLS ALPN) validation method proves control over a domain name by requiring the client to configure a TLS server referenced by the DNS A and/or  Resource Records for the domain name to respond to specific connection attempts utilizing the ALPN extension {{!RFC7301}}. The server validates control of the domain name by connecting to the TLS server and verifying a certificate with specific content is presented.

type (required, string):
: The string "tls-alpn-01"

token (required, string):
: A random value that uniquely identifies the challenge.  This value MUST have
at least 128 bits of entropy. It MUST NOT contain any characters outside the
base64url alphabet, including padding characters ("=").

~~
GET /acme/authz/1234/1 HTTP/1.1
Host: example.com

HTTP/1.1 200 OK
{
  "type": "tls-alpn-01",
  "url": "https://example.com/acme/authz/1234/1;,
  "status": "pending",
  "token": "evaGxfADs6pSRb2LAv9IZf17Dt3juxGJ-PCt92wr-oA"
}
~~

The client prepares for validation by constructing a self-signed certificate which MUST contain a acmeValidation-v1 extension and a subjectAlternativeName extension {{!RFC5280}}. The subjectAlternativeName extension MUST contain a single dNSName entry where the value is the domain name being validated. The acmeValidation-v1 extension MUST contain the SHA-256 digest [FIPS180-4] of the key authorization {{draft-ietf-acme-acme}} for the challenge. The acmeValidation extension MUST be critical so that the certificate isn't inadvertently used to make trust decisions.

id-pe-acmeIdentifier OBJECT IDENTIFIER ::=  { id-pe 30 }

id-pe-acmeIdentifier-v1 OBJECT IDENTIFIER ::=  { id-pe-acmeIdentifier 1 }

acmeValidation-v1 ::= OCTET STRING (SIZE (32))

Once this certificate has been created it MUST be provisioned such that it is returned during a TLS handshake that contains a ALPN extension containing the value "acme-tls/1" and a SNI extension containing the domain name being validated. 

When ready the client acknowledges this by sending a POST message containing the key authorization, as defined in draft-ietf-acme-acme section 8.1, to the challenge URL.

keyAuthorization (required, string):
: The key authorization for this challenge.  This value MUST match the token
from the challenge and the client's account key.

~~
POST /acme/authz/1234/1
Host: example.com
Content-Type: application/jose+json

{
  "protected": base64url({
"alg": "ES256",
"kid": "https://example.com/acme/acct/1;,
"nonce": "JHb54aT_KTXBWQOzGYkt9A",
"url": "https://example.com/acme/authz/1234/1;
  }),
  "payload": base64url({
"keyAuthorization": "evaGxfADs...62jcerQ"
  }),
  "signature": "Q1bURgJoEslbD1c5...3pYdSMLio57mQNN4"
}
~~


On receiving this the server MUST verify that the key authorization in the request matches the "token" value in the challenge and the client's account key. If they do not match then the server MUST return a HTTP error in response to the POST request in which the client sent the challenge.

The server then verifies the client's control over the domain by verifying that the TLS server was configured as expected using these steps:

1. Compute the expected SHA-256 [FIPS180-4] digest of the expected key authorization.
2. Initiate a TLS connection with the domain name being validated, this