Subject: [Acme] Time for ACME-CAA discussion at 102

From: Roland Shoemaker <[email-masked]>
Date: Mon, 16 Jul 2018 20:08:24 -0700

I know this is quite late but could we reserve some time for a discussion of the (possible) pending issues with regard to the parameter format mismatch between ACME-CAA and 6844 and possible solutions.

Thanks!
Roland

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Jul 2018 03:44:17 +0000

Yes, you can go right after the main acme doc

On 7/16/18, 11:08 PM, "Roland Shoemaker" <[email-masked]> wrote:

    Thanks!
    Roland

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Mon, 16 Jul 2018 23:08:13 -0700

Great, thanks!

> On Jul 16, 2018, at 8:44 PM, Salz, Rich <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Jul 2018 10:04:48 +0300

On Mon, Jul 16, 2018 at 08:08:24PM -0700, Roland Shoemaker wrote:
> I know this is quite late but could we reserve some time for a
> discussion of the (possible) pending issues with regard to the
> parameter format mismatch between ACME-CAA and 6844 and possible
> solutions.

I took a look at the issue:

The RFC 6844 grammar is ambiguous due to incorrect multiplicities.
As far as I can see, there is no erratum for this.

As an example, consider the multiple-parameter example from the
ACME-CAA document:

issue "example.net; accounturi=https://example.net/account/2345; validationmethods=http-01"

This has unique valid meanings for both RFC6844 and RFC6844bis
grammars, but the two are different! Even taking additional constraint
that accounturi value is an uri is no help.

Now, under RFC6844bis rules, one can presumably rewrite this rule into:

issue "example.net;accounturi=https://example.net/account/2345;validationmethods=http-01"

The RFC6844bis parse is still the same, but now there are 18(!)
possible meanings under RFC6844 rules. One of those is the same as
the above. However, what I think is the most sensible way to
fix the RFC6844 grammar gives different meaning from the first
example (this can not alter the first example, because there the
meaning is unique already). And restriction to URI does not help
here either.

Another rewrite under RFC6844bis rules would be:

issue "example.net;accounturi=https://example.net/account/2345 ; validationmethods=http-01"

RFC6844bis parse is still the same, but RFC6844 rules would reject this
as invalid.

RFC6844 and RFC6844bis grammars have all of:

- Strings that are valid in RFC6844 but not RFC6844bis.
- Strings that are valid in RFC6844bis but not RFC6844.
- Strings that have unique different meanings for RFC6844 and
  RFC6844bis.
- Strings that have unque meaning in RFC6844bis, but 
  multiple meanings in RFC6844, all different from the
  unique meaning in RFC6844bis.

If one fixes the RFC6844 grammar in most obvious way (by disallowing
zero space between parameters, which is the source of ambiguous cases),
then:

- Strings that are valid in RFC6844(fixed) but not RFC6844bis.
- Strings that are valid in RFC6844bis but not RFC6844(fixed).
- Strings that have unique different meanings for RFC6844(fixed) and
  RFC6844bis.

Since the language is not changed by the fix, the last two cases
with unfixed RFC6844 are collapsed into the last case.

-Ilari

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 17 Jul 2018 13:08:28 +0000

Yes, the RFC 6844 grammar is a mess, and it has significantly impeded
efforts to improve CAA.  It's one of the things I think is most important to
fix in 6844bis.

It is particularly troubling because CABF rules point to 6844, and some
people have been sticklers about requiring very strict compliance with RFCs
that are pointed to by the BRs.  For 6844, it's often very unclear what's
compliant, as the document is often ambiguous, and contradicts itself and
other well-known RFCs!

I'm a big fan of CAA (as long as it isn't used anti-competitively ...), but
6844 has been an endless source of headaches.  High quality analysis like
Ilari's will go a long way towards helping us make 6844bis much better...

-Tim

> -----Original Message-----
> From: Acme [mailto:[email-masked]] On Behalf Of Ilari Liusvaara
> Sent: Tuesday, July 17, 2018 3:05 AM
> To: Roland Shoemaker <[email-masked]>
> Cc: Salz, Rich <[email-masked]>; [email-masked]
> Subject: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for
> ACME-CAA discussion at 102)
> 
> As an example, consider the multiple-parameter example from the ACME-CAA
> document:
> 
> This has unique valid meanings for both RFC6844 and RFC6844bis grammars,
> but the two are different! Even taking additional constraint that
accounturi
> value is an uri is no help.
> 
> issue
> "example.net;accounturi=https://example.net/account/2345;validationmetho
> ds=http-01"
> 
> The RFC6844bis parse is still the same, but now there are 18(!) possible
> meanings under RFC6844 rules. One of those is the same as the above.
> However, what I think is the most sensible way to fix the RFC6844 grammar
> gives different meaning from the first example (this can not alter the
first
> example, because there the meaning is unique already). And restriction to
URI
> does not help here either.
> 
> RFC6844bis parse is still the same, but RFC6844 rules would reject this as
> invalid.
> 
> 
> 
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Jul 2018 13:25:51 +0000

Ilari,

That is a very impressive discussion of the issues, and examples.  Thank you very much!

So, what should the WG do with the CAA challenge document?

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 17 Jul 2018 13:39:29 +0000

My personal opinion is that the WG should try to come up with something that
makes sense and complies with the intent of 6844 and its examples, instead
of trying to be overly strict about complying with the current grammar as
written.

We can then file an errata and work with LAMPS to fix up the grammar to
unambiguously state what we want it to in 6844bis.

It's unfortunate to be in this position, but I think it's the only
reasonable path forward.

-Tim

> From: Acme [mailto:[email-masked]] On Behalf Of Salz, Rich
> Sent: Tuesday, July 17, 2018 9:26 AM
> To: Ilari Liusvaara <[email-masked]>; Roland Shoemaker
> <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Acme] ACME-CAA vs. RFC6844 vs. RFC6844bis (Was: Re: Time for
> That is a very impressive discussion of the issues, and examples.  Thank
you
> very much!

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Jul 2018 18:36:51 +0300

> So, what should the WG do with the CAA challenge document?

I think either:

- Change reference to RFC6844bis.
- Fix examples (and other text) to be consistent with the RFC6844
  grammar (which pretty obviously splits on space/tab according to
  the grammar).

-Ilari

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 17 Jul 2018 15:38:57 +0000

We could also add text saying "be liberal in what you expect" as the community is migrating, I suppose.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 17 Jul 2018 18:39:47 +0300

> efforts to improve CAA.  It's one of the things I think is most important to

The main problem in my opinion with RFC6844 grammar is the examples
that contradict it. Yes, the grammar does have the problem that it is
ambiguous, but it seems that running into this problem is unlikely in
real world, as the inputs required are pretty odd.

In practicular, if someone tries to implment RFC6844 grammar:

- They handroll the parser. With high likehood, the parser picks the
  obvious meaning of the input (because it is far the simplest to
  implement the parser that way).
- They use parser generator, but accidentially misenter the grammar in
  a way that fixes the problem. With high likehood, this is also the
  obvious meaning (because it is the easiest to specify).
- They use parser generator and correctly enter the grammar. In this
  case, the parser generator would probably complain about the grammar
  (most parser generators do not handle general context-free grammars).
  If the buggy parser makes it into production, it will still handle
  most of the inputs seen in the real world.

> Ilari's will go a long way towards helping us make 6844bis much better...

On the other hand, I find the existence of inputs that parse in both
RFC6844 and RFC6844bis but differently quite troublesome. Especially
given that these inputs are not necressarily rare in the real world.

Also, if someone uses RFC6844bis CAA records containing multiple
parameters with a CA that uses RFC6844 CAA records, that is likely
discovered fairly quickly as the misparsed parameters probably cause
things to blow up.

However, if someone uses RFC6844 CAA records with multiple parameters
with a CA that uses RFC6844bis CAA records and does not use parser
that treat unparseable records as unsatisfiable or have handrolled
parser that misparses the thing in a really whacky way, you have fail-
open situation on your hands.

I say that it would be nice if CAs treated issue records with
unknown parameters or parse errors as unsastisfiable (as this makes
errors much more likely to fail closed and fixed than to fail open
and lurk as security problems). I do not offhand know if this is
already required or not.

-Ilari

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 17 Jul 2018 15:46:47 +0000

Yeah, I'm not particularly picky on the solution as long as we agree on a
solution
that works.  I believe that parameter usage is pretty rare in the wild right
now,
so I think we have time to come to a consensus about what the right behavior
is,
and document it via fixing examples or errata or whatever *before* the
problems
that Ilari rightly points out bite us in practice.

There is a precedent for putting approved errata directly into the BRs to
avoid
"diversity of interpretations", which generally causes problems.  I'd prefer
to
not have to be liberal on expectations, and indeed would support policy
proposal
at CABF to require rejection and non-issuance in the case of non-compliant
or
ambiguous CAA tags.  It's safer.

-Tim

> Sent: Tuesday, July 17, 2018 11:39 AM
> To: Ilari Liusvaara <[email-masked]>
> Cc: [email-masked]; Roland Shoemaker <[email-masked]>
> A standards-track document cannot reference a draft.  So either we wait,
or'm 
> we wait for an errata to be written and accepted, or we do this:
>

---

From: Corey Bonnell <[email-masked]>
Date: Tue, 17 Jul 2018 15:47:21 +0000

Hi Ilari,
Unfortunately, the situation is even more grave than allowing 0-length whitespace delimiters, as section 3 and section 5.2 of RFC 6844 contradict each other in regard to the delimiter (section 3 specifies the parameter delimiter as a semicolon, whereas in section 5.2 it's "0 or more whitespace characters"). This was pointed out in erratum 5200 (https://www.rfc-editor.org/errata/eid5200). These layers of brokenness lead me to believe that no one should be specifying multiple parameters in issue/issuewild records until these issues are corrected in 6844-bis, lest they might experience incompatibilities between CAA record handling implementations.

 Thanks,
Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com <http://www.trustwave.com/>

On 7/17/18, 11:38 AM, "Acme on behalf of Ilari Liusvaara" <[email-masked] on behalf of [email-masked]> wrote:

    I think either:

    -Ilari
    
    _______________________________________________
    Acme mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=_Y3O2yMmFUlzwyE4YBLSgZbkB1nVwb8L7Z2YF_UTJg&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 13:17:26 +0000

Ilari,

Would you be willing and able to write, or co-write, a 6844 errata that corrected that document so that the current ACME CAA draft was compliant?  At the WG meeting yesterday, we got feedback that this would be acceptable to the Area Director, and everyone agrees it is a much better solution than waiting for the 6844bis document to become an RFC.

And again, thanks for your detailed analysis!

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Jul 2018 17:28:46 +0300

On Wed, Jul 18, 2018 at 01:17:26PM +0000, Salz, Rich wrote:
> 
> Would you be willing and able to write, or co-write, a 6844 errata
> that corrected that document so that the current ACME CAA draft was
> compliant?  At the WG meeting yesterday, we got feedback that this
> would be acceptable to the Area Director, and everyone agrees it
> is a much better solution than waiting for the 6844bis document to
> become an RFC.

In my opinion, there is significant difference between:

- Fixing the ambiguous behavior in RFC6844 grammar in a way that
  does not change the language (which means the set of strings that
  are valid in grammar) but fixes the ambiguous cases.
- Changing the RFC6844 language to make it parse the examples from
  ACME-CAA as the draft intends them to be parsed. Even if this
  grammar would match the examples from the document.

As reminded by recent change from validation-methods to
validationmethods, there apparently are DNS provoders that do check
what is entered against the language.

The no-change-to-language fixed grammar changes would look something
like (omitting unchanged symbols 'domain', 'parameter' and 'space' and
any symbols transitively used by those three):

issuevalue = space [domain space] [";" space [parameters space]]
parameters = parameter *(mspace parameter)
mspace = 1*(SP / HTAB)

(Hope I got that right) But this does not parse the examples from
ACME-CAA correctly. For example:

issue "example.net; accounturi=https://example.net/account/1234; validationmethods=dns-01"

would parse as:

space: ""
domain: "example.net"
space: ""
space: ""
parameters:
	parameter:
		tag: "accounturi"
		value: "https://example.net/account/1234;"
	mspace: " "
	parameter:
		tag: "validationmethods"
		value: "dns-01"
space: ""

Note the trailing ';' in the account URI.

Notes about the construction:

- The reason why the space symbols are inside optional blocks is
  to avoid two back-to-back space symbols, as that would allow
  ambiguous parse of some strings.
- I introduced mspace symbol (short from "mandatory space") to
  stand for at least one space in order to separate parameters..

I also found a minor issue with the RFC6844bis grammar: It has
possibility of having two back-to-back *WSP symbols that can
compete with each other. One possible fix would be:

issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]]

Which ensures there is always a non-empty symbol (domain or
parameters, neither of which can be empty and neither of which
can start or end with WSP) between two *WSP sybmbols.

-Ilari

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 18 Jul 2018 17:33:10 +0000

Hi Ilari,
You're correct about the ambiguity in 6844-bis regarding whitespace handling in the issuevalue production rule. I sent a message to LAMPS (https://www.ietf.org/mail-archive/web/spasm/current/msg01466.html) to get this corrected in 6844-bis, referencing your email.

Thanks,
Corey

On 7/18/18, 10:29 AM, "Acme on behalf of Ilari Liusvaara" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    issue "http://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5pH_j3xvMw&s=5&u=http%3a%2f%2fexample%2enet%3b accounturi=https://example.net/account/1234; validationmethods=dns-01"
    
    would parse as:
    
    space: ""
    domain: "http://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5s2t1CttZA&s=5&u=http%3a%2f%2fexample%2enet"
    space: ""
    space: ""
    parameters:
    	parameter:
    		tag: "accounturi"
    		value: "https://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5sP91CtsPg&s=5&u=https%3a%2f%2fexample%2enet%2faccount%2f1234%3b"
    	mspace: " "
    	parameter:
    		tag: "validationmethods"
    		value: "dns-01"
    space: ""

    

    

    -Ilari
    
    _______________________________________________
    Acme mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=vM7P2-IdIAR0aSvyVFMWRv8J93MJNR3h5pao3SFjNA&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2facme

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jul 2018 17:40:10 +0000

We are interested in the latter.  Folks in the room opined that parameters are not used much.  Are you willing to write such a thing?  (No problem, if not.)

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Jul 2018 21:38:28 +0300

On Wed, Jul 18, 2018 at 05:40:10PM +0000, Salz, Rich wrote:
> We are interested in the latter.  Folks in the room opined that parameters
> are not used much.  Are you willing to write such a thing?  (No problem,
> if not.)

Maybe copy the grammar from RFC6844bis, fix the whitespace and formatting
issues and remove the dashes in tags?

The result looks something like:

domain = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT))

parameters = (parameter *WSP ";" *WSP parameters) / parameter
parameter = tag *WSP "=" *WSP value
tag = (ALPHA / DIGIT) *(ALPHA / DIGIT)
value = *(%x21-3A / %x3C-7E)

AFAICT, for arbitrary issue directive one can write in this grammar,
there exists an equivalent issue directive that is in the original
RFC6844 language (possibly with different meaning). Also, this grammar
matches the informal description of multi-paramaeter records in
RFC6844.

-Ilari