Re: [Acme] I-D Action: draft-ietf-acme-caa-05.txt

[Jacob Hoffman-Andrews]

Thanks for the update, Hugo! Let's Encrypt's Boulder has merged a change 
updating to match this behavior, which should go out to our staging 
environment on Tuesday.


https://github.com/letsencrypt/boulder/pull/3772

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

Re: [Acme] I-D Action: draft-ietf-acme-caa-05.txt

[Hugo Landau]

> 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   : CAA Record Extensions for Account URI and ACME 
> Method Binding
> Author  : Hugo Landau
>   Filename: draft-ietf-acme-caa-05.txt
>   Pages   : 9
>   Date: 2018-06-21
This revision removes the hyphens from what were previously the
"account-uri" and "validation-methods" parameters, which are now
"accounturi" and "validationmethods". This change enhances compliance
with the ABNF grammar in the CAA specification.

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

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Hugo Landau]

> It seems the quickest way to address this is to remove the hyphens from the 
> labels and continue progressing the doc.
> 
> Hugo, can you do this in the next few days, or should we (chairs) find 
> someone else?
Done.

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

[Acme] I-D Action: draft-ietf-acme-caa-05.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   : CAA Record Extensions for Account URI and ACME Method 
Binding
Author  : Hugo Landau
Filename: draft-ietf-acme-caa-05.txt
Pages   : 9
Date: 2018-06-21

Abstract:
   The CAA DNS record allows a domain to communicate issuance policy to
   CAs, but only allows a domain to define policy with CA-level
   granularity.  However, the CAA specification also provides facilities
   for extension to admit more granular, CA-specific policy.  This
   specification defines two such parameters, one allowing specific
   accounts of a CA to be identified by URI and one allowing specific
   methods of domain control validation as defined by the ACME protocol
   to be required.


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

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

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


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] tls-alpn-01 spec: TLS-SNI history

[Ryan Sleevi]

On Thu, Jun 21, 2018 at 1:40 PM, Tim Hollebeek 
wrote:

> So the disagreement is whether the it is sufficient to merely use the name
> for the
>
> DNS lookup, and then accept whatever happens afterwards, or whether the
> intent
>
> was that the web page should be retrieved in much the same way as it is
> retrieved by
>
> browsers.  Matching them as closely as possible makes the validation more
> reliable.
>

I think TLS-ALPN documents why this is true, but we know multiple CAs that
implemented either TLS-SNI or alternatives viewed it the same at the time.
I am greatly appreciative of hindsight being 20/20, but I think it's
important to recall that it is hindsight. As part of the introduction of
3.2.2.4.10, CAs were actively discussing about how this avoids the need to
do such matches, and the CA/Browser Forum Validation WG acknowledged it as
a correct interpretation. This is not about strict interpretations - this
is about documented and uncontested discussion in the Validation WG.

However, as to the remainder of the message, it seems we're echoing each
other - that a well-specified TLS-ALPN that concretely documents the
processing mode is of great benefit to the community, both in terms of
client implementers knowing what edge cases to expect that may cause an
ACME server to reject their response, and ACME servers to consider in
implementing when considering the validation level of the client's request.
My hope, then, is that any energy that might be directed at trying to
duplicate this work in 3.2.2.4.10 in the CA/Browser Forum might otherwise
be more productively and holistically directed at this effort within the
IETF and TLS-ALPN, allowing both broader participation and review, and
resulting in a state such that 3.2.2.4.10 can simply be replaced,
wholesale, with a statement "Using TLS-ALPN as specified is acceptable".


> Unfortunately, historically, the requirements are underspecified, and
> there is freedom
>
> to implement the validation mechanism badly.  There are improvements
>
> that were discussed in the excellent discussion in Virginia, but even
> today, we
>
> aren’t there yet.  So yes, it is possible by using a very strict,
> technical reading,
>
> an argument can be made that TLS-SNI is compliant.
>


>
>
> I’m just not a fan of that argument.  When the BRs say “retrieve a […] web
> page”, I
>
> believe that includes a responsibility to interpret that provision in a
> way that meets
>
> the intent of the validation method, and doesn’t introduce security risks.
>
>
>
> -Tim
>
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Tim Hollebeek]

I agree with Ryan that that’s probably the best way forward, if changing the 
names to remove the hyphens doesn’t cause undue hardship.

 

-Tim

 

From: Salz, Rich [mailto:rs...@akamai.com] 
Sent: Thursday, June 21, 2018 9:07 AM
To: Tim Hollebeek ; Ivan Ristic 
; Ryan Sleevi 
Cc: IETF ACME ; Hugo Landau ; Roland 
Shoemaker 
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

 

It seems the quickest way to address this is to remove the hyphens from the 
labels and continue progressing the doc.

 

Hugo, can you do this in the next few days, or should we (chairs) find someone 
else?

 

From: Tim Hollebeek mailto:tim.holleb...@digicert.com> >
Date: Thursday, June 21, 2018 at 8:30 AM
To: "ivan.ris...@gmail.com  " 
mailto:ivan.ris...@gmail.com> >, Ryan Sleevi 
mailto:ryan-i...@sleevi.com> >
Cc: "acme@ietf.org  " mailto:acme@ietf.org> >, Hugo Landau mailto:hlan...@devever.net> >, Roland Shoemaker mailto:rol...@letsencrypt.org> >
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

 

The current ABNF in 6844 is basically broken, and doesn’t express what it was 
intended to express.  I remember staring at it with Corey and wondering how it 
got approved …

 

So while I’m not particularly picky on the exact bureaucratic details of how a 
fix gets made, it would be nice to get this resolved quickly via an errata or 
whatever.  There are a bunch of reasonable extensions to CAA that could be made 
in the future, and a solid and agreed-upon grammar is a necessary prerequisite.

 

Another option (at least for uses on the Web PKI) is clarification by CABF 
ballot.  Despite all the downsides of CABF, it does have the ability to move 
pretty quickly when it needs to.

 

-Tim

 

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ivan Ristic
Sent: Thursday, June 21, 2018 3:41 AM
To: Ryan Sleevi mailto:ryan-i...@sleevi.com> >
Cc: IETF ACME mailto:acme@ietf.org> >; Hugo Landau 
mailto:hlan...@devever.net> >; Roland Shoemaker 
mailto:rol...@letsencrypt.org> >
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

 

Just to add to this, those CAs whose CAA processing follows the current spec 
will likely see all CAA policies with ACME-CAA extensions as invalid, 
potentially leading to operational issues. It's going to be the same with tools 
that inspect and validate CAA (e.g., our tool, Hardenize).

 

On Wed, Jun 20, 2018 at 10:25 PM, Ryan Sleevi mailto:ryan-i...@sleevi.com> > wrote:

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker mailto:rol...@letsencrypt.org> > wrote:

As previously discussed on the list the two property names defined in 
draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform to 
the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this by 
expanding the ABNF to be less restrictive but for now this doesn’t really 
address the problem at hand.

Given it is probably unlikely that 6844-bis will be standardized any time soon 
is there any plan to make changes to draft-ietf-acme-caa to address this in the 
short term? Given we are not yet at the point where there is wide 
deployment/adoption of this feature can we take the easy route and simply 
remove the hyphens so that the document at least complies with the existing CAA 
document?

 

It is not just that -bis would need to be finalized and standardized, but that 
CAs would also have to adopt and recognize the syntax in -bis, updating their 
6844 implementations. Even if -bis were final tomorrow, that would still take 
considerable time, given the normative differences, and so I think aligning on 
an inter-operable expression is certainly preferable, allowing it to work with 
both 6844 and -bis.


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





 

-- 

Ivan



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

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Tim Hollebeek]

So the disagreement is whether the it is sufficient to merely use the name for 
the

DNS lookup, and then accept whatever happens afterwards, or whether the intent 

was that the web page should be retrieved in much the same way as it is 
retrieved by

browsers.  Matching them as closely as possible makes the validation more 
reliable.

 

Unfortunately, historically, the requirements are underspecified, and there is 
freedom

to implement the validation mechanism badly.  There are improvements 

that were discussed in the excellent discussion in Virginia, but even today, we

aren’t there yet.  So yes, it is possible by using a very strict, technical 
reading,

an argument can be made that TLS-SNI is compliant.

 

I’m just not a fan of that argument.  When the BRs say “retrieve a […] web 
page”, I

believe that includes a responsibility to interpret that provision in a way 
that meets

the intent of the validation method, and doesn’t introduce security risks.

 

-Tim

 

On Thu, Jun 21, 2018 at 8:40 AM, Tim Hollebeek mailto:tim.holleb...@digicert.com> > wrote:


> TLS-ALPN addresses the latter problem by requiring the server_name to match
> the validation target (which is AFACIT also required by the Baseline
> Requirements). This stops claiming arbitary names from allowing
> misvalidations.

This was certainly the intent.  Never in over two years of some pretty
detailed discussions about the mechanics of validation did anyone ever
propose it was reasonable to validate domain name A by contacting
the web server for a name that is not A (except for the approved the _prefix 
stuff).

 

That's not what is done under TLS-SNI.



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

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Felipe Gasper]

> On Jun 21, 2018, at 10:53 AM, Ilari Liusvaara  
> wrote:
> 
> On Thu, Jun 21, 2018 at 09:53:07AM -0400, Felipe Gasper wrote:
> 
>> I would guess that the reason why Apache didn’t get much grief over
>> TLS-SNI is that many--most?--hosting services require a certificate
>> to match one or more domains on the associated Apache virtual host.
>> But that’s not universal by any stretch.
> 
> Also, getting the default virtual host on most hosting services is
> probably not easy. And without default vhost, you can only answer to
> names you have.

At least one entity on every IP address has it. And it’s trivial for anyone to 
check to see who it is.

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

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Ryan Sleevi]

On Thu, Jun 21, 2018 at 8:30 AM, Tim Hollebeek 
wrote:

> The current ABNF in 6844 is basically broken, and doesn’t express what it
> was intended to express.  I remember staring at it with Corey and wondering
> how it got approved …
>

>
> So while I’m not particularly picky on the exact bureaucratic details of
> how a fix gets made, it would be nice to get this resolved quickly via an
> errata or whatever.  There are a bunch of reasonable extensions to CAA that
> could be made in the future, and a solid and agreed-upon grammar is a
> necessary prerequisite.
>
>
>
> Another option (at least for uses on the Web PKI) is clarification by CABF
> ballot.  Despite all the downsides of CABF, it does have the ability to
> move pretty quickly when it needs to.
>
>
>
> -Tim
>

I would like to focus on resolving the issues with the document, as
written, as it specifies a grammar not conformant with 6844.

I disagree with your assessments about intent, brokenness, or possible
solutions for 6844 - but those are all better for LAMPS to work out, and we
can have that reasonable debate there. I hope, though, we're in agreement
that conforming implementations of 6844 cannot and should not process these
records, and as Ivan calls out, runs real operational risk to users that
rely on them. Let's fix that, now, and worry about whether or not we can
break compatibility in a -bis document and whether it's worth it.
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] tls-alpn-01 spec: TLS-SNI history

[Tim Hollebeek]

> TLS-ALPN addresses the latter problem by requiring the server_name to match
> the validation target (which is AFACIT also required by the Baseline
> Requirements). This stops claiming arbitary names from allowing
> misvalidations.

This was certainly the intent.  Never in over two years of some pretty
detailed discussions about the mechanics of validation did anyone ever
propose it was reasonable to validate domain name A by contacting
the web server for a name that is not A (except for the approved the _prefix 
stuff).

I realize that after it was pointed out that TLS-SNI was horribly broken
in this regard, there were attempts by some to retroactively claim that
such behavior was compliant, but I always found those explanations a
bit tortured and unconvincing.  Certainly if I a large commercial CA had
made them, they would have been laughed at and ridiculed.

I would actually love to work with some people on updating the CABF
method 10 validation requirements in order to properly express the
security requirements that ALPN-01 satisfies.  The whole TLS-SNI
experience showed that Method 10 does not have sufficiently rigorous
requirements to guarantee it actually validates what it claims to validate.
Since the CABF VWG is currently working on adding more security rigor
to all the approved validation methods, it would be a great time to fix
up Method 10.

ALPN-01 is a much better validation method, and I'm very thankful
to all the people who worked hard to come up with a replacement,
which as far as I can tell from looking at it briefly (I wish I had more time)
looks pretty secure and robust.

-Tim


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

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Tim Hollebeek]

The current ABNF in 6844 is basically broken, and doesn’t express what it was 
intended to express.  I remember staring at it with Corey and wondering how it 
got approved …

 

So while I’m not particularly picky on the exact bureaucratic details of how a 
fix gets made, it would be nice to get this resolved quickly via an errata or 
whatever.  There are a bunch of reasonable extensions to CAA that could be made 
in the future, and a solid and agreed-upon grammar is a necessary prerequisite.

 

Another option (at least for uses on the Web PKI) is clarification by CABF 
ballot.  Despite all the downsides of CABF, it does have the ability to move 
pretty quickly when it needs to.

 

-Tim

 

From: Acme [mailto:acme-boun...@ietf.org] On Behalf Of Ivan Ristic
Sent: Thursday, June 21, 2018 3:41 AM
To: Ryan Sleevi 
Cc: IETF ACME ; Hugo Landau ; Roland 
Shoemaker 
Subject: Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

 

Just to add to this, those CAs whose CAA processing follows the current spec 
will likely see all CAA policies with ACME-CAA extensions as invalid, 
potentially leading to operational issues. It's going to be the same with tools 
that inspect and validate CAA (e.g., our tool, Hardenize).

 

On Wed, Jun 20, 2018 at 10:25 PM, Ryan Sleevi mailto:ryan-i...@sleevi.com> > wrote:

On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker mailto:rol...@letsencrypt.org> > wrote:

As previously discussed on the list the two property names defined in 
draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform to 
the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this by 
expanding the ABNF to be less restrictive but for now this doesn’t really 
address the problem at hand.

Given it is probably unlikely that 6844-bis will be standardized any time soon 
is there any plan to make changes to draft-ietf-acme-caa to address this in the 
short term? Given we are not yet at the point where there is wide 
deployment/adoption of this feature can we take the easy route and simply 
remove the hyphens so that the document at least complies with the existing CAA 
document?

 

It is not just that -bis would need to be finalized and standardized, but that 
CAs would also have to adopt and recognize the syntax in -bis, updating their 
6844 implementations. Even if -bis were final tomorrow, that would still take 
considerable time, given the normative differences, and so I think aligning on 
an inter-operable expression is certainly preferable, allowing it to work with 
both 6844 and -bis.


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





 

-- 

Ivan



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

Re: [Acme] Handling non-conformant CAA property names in ACME-CAA

[Ivan Ristic]

Just to add to this, those CAs whose CAA processing follows the current
spec will likely see all CAA policies with ACME-CAA extensions as invalid,
potentially leading to operational issues. It's going to be the same with
tools that inspect and validate CAA (e.g., our tool, Hardenize).

On Wed, Jun 20, 2018 at 10:25 PM, Ryan Sleevi  wrote:

> On Wed, Jun 20, 2018 at 4:47 PM, Roland Shoemaker 
> wrote:
>
>> As previously discussed on the list the two property names defined in
>> draft-ietf-acme-caa, "validation-methods” and "account-uri”, do not conform
>> to the ABNF syntax in RFC 6844 as they contain hyphens. 6844-bis fixes this
>> by expanding the ABNF to be less restrictive but for now this doesn’t
>> really address the problem at hand.
>>
>> Given it is probably unlikely that 6844-bis will be standardized any time
>> soon is there any plan to make changes to draft-ietf-acme-caa to address
>> this in the short term? Given we are not yet at the point where there is
>> wide deployment/adoption of this feature can we take the easy route and
>> simply remove the hyphens so that the document at least complies with the
>> existing CAA document?
>>
>
> It is not just that -bis would need to be finalized and standardized, but
> that CAs would also have to adopt and recognize the syntax in -bis,
> updating their 6844 implementations. Even if -bis were final tomorrow, that
> would still take considerable time, given the normative differences, and so
> I think aligning on an inter-operable expression is certainly preferable,
> allowing it to work with both 6844 and -bis.
>
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
>


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