Subject: Re: [lamps] New draft: rfc6844bis

From: Corey Bonnell <[email-masked]>
Date: Tue, 10 Jul 2018 13:58:32 +0000

Hi Jacob,
Thanks for getting the 6844-bis draft together. Your phrasing on the proper handling of non-empty CAA record sets that don't contain issue/issuewild tags is clear and should make this particular scenario unambiguous.

It looks like the updated ABNF grammar for the issue property tag is missing some line breaks, as several of the production rules are now on the same line.

There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server). This was originally mentioned in https://blog.cloudflare.com/caa-of-the-wild/, but I don't think this has been brought up on this mailing list before and thought we should at least discuss it. My opinion is that it should remain a "SHOULD" in the RFC, otherwise the RFC is dictating policy. The preferable route is to define required lookup properties in policy explicitly (eg, the Baseline Requirements would dictate that all lookups MUST be performed against an authoritative nameserver).

Thanks,
Corey Bonnell
Senior Software Engineer

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

On 5/31/18, 2:47 PM, "Spasm on behalf of Jacob Hoffman-Andrews" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,
    
    I've uploaded rfc6844bis 
    (https://scanmail.trustwave.com/?c=4062&d=o8OQ2yujgVEeFlV5bl_Op4ySAduGL3C5TmGWzUjgqQ&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-lamps-rfc6844bis-00%29 which is 
    the WG version of 
    https://scanmail.trustwave.com/?c=4062&d=o8OQ2yujgVEeFlV5bl_Op4ySAduGL3C5TmPEnEi3pA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-hoffman-andrews-caa-simplification-03 
    Differences versus the last draft:
    
    - Adopted Corey's improved ABNF grammar, which also allows hyphens in 
    property names, and spaces around the equal signs in properties.
    - Clarified how to handle CAA RRsets that have no issue or issuewild 
    tags, but do have other CAA tags. Thanks for the proposal on this, Corey!
    - Added a "Differences vs RFC 6844" section.
    - Emptied the IANA Considerations section, which was copied from RFC6844 
    but irrelevant because the values in it had already been registered with 
    IANA.
    - Added a section to "Deployment Considerations" regarding private 
    nameservers.
    - Improved the wording of "Bogus DNSSEC Responses" section (under 
    "Deployment Considerations").
    
    If you would like to read the individual commits, they are available at 
    https://scanmail.trustwave.com/?c=4062&d=o8OQ2yujgVEeFlV5bl_Op4ySAduGL3C5TjKZyk29rg&s=5&u=https%3a%2f%2fgithub%2ecom%2fjsha%2fcaa-simplification%2fcommits%2fmaster
    
    Thanks,
    Jacob
    
    _______________________________________________
    Spasm mailing list
    [email-masked]
    https://scanmail.trustwave.com/?c=4062&d=o8OQ2yujgVEeFlV5bl_Op4ySAduGL3C5Tj6Snknk_A&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2fspasm

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 17 Jul 2018 15:45:28 -0700

> It looks like the updated ABNF grammar for the issue property tag is missing some line breaks, as several of the production rules are now on the same line.
Thanks. I've fixed this in my working copy, and it will make it into the 
next revision.

> There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For exa…
Yeah, I agree we should keep this as a SHOULD. I think defining what 
exactly it means could get messy. For instance, CAs are likely to use an 
internal recursive resolver, which in turn contacts a series of 
authoritative resolvers.

---

From: Corey Bonnell <[email-masked]>
Date: Wed, 18 Jul 2018 16:04:12 +0000

A bit ago, Ilari Liusvaara pointed out on the ACME WG list (https://www.ietf.org/mail-archive/web/acme/current/msg02845.html) that the grammar in 6844-bis has a minor issue in regard to multiple whitespace character sequences, as the grammar produces ambiguous parses in that case. I agree with his analysis and proposed fix to the issuevalue production rule:

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

Thanks, 
Corey

On 7/17/18, 6:45 PM, "Jacob Hoffman-Andrews" <[email-masked]> wrote:

    > There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server). This was originally mentioned in https://scanmail.trustwave.com/?c=4062&d=ivHO2xmUBfppFKh1daO2Kedy9FsSnsVXKPKouCUq5Q&s=5&u=https%3a%2f%2fblog%2ecloudflare%2ecom%2fcaa-of-the-wild%2f but I don't think this has been brought up on this mailing list before and thought we should at least discuss it. My opinion is that it should remain a "SHOULD" in the RFC, otherwise the RFC is dictating policy. The preferable route is to define required lookup properties in policy explicitly (eg, the Baseline Requirements would dictate that all lookups MUST be performed against an authoritative nameserver).

---

From: Sean Leonard <[email-masked]>
Date: Thu, 19 Jul 2018 09:51:46 -0400

Looks like a good fix.

Please confirm results with abnfgen <http://www.quut.com/abnfgen/>.

Sean

> On Jul 18, 2018, at 12:04 PM, Corey Bonnell <[email-masked]> wrote:
> 
> https://www.ietf.org/mailman/listinfo/spasm