[cabf_validation] Designated Authorization Domain Label (method F) write-up

[Ryan Sleevi]

On Wed, Apr 25, 2018 at 11:47 AM, Corey Bonnell <CBonnell at trustwave.com>
wrote:

> Hi Ryan,
>
> Thank you for your feedback. Please see the responses to your concerns
> below:
>
>
>
> *1) I do not support this normative redefinition of "Authorization Domain
> Name". I do not think algorithms like this belong in a Definitions section,
> and more work should be done to better normatively specify that.*
>
>
>
> Inspired by the proposed Method C and D in the Validation Summit Findings
> document, I redefined Authorization Domain Name as it was a singular
> location that I could update to describe how I envisioned “Method F” to
> work. I agree the Definitions section is a strange place to put this
> algorithm, and would not be opposed to define it in another location
> (perhaps in Section 3.2.2.4 or the Appendix). However, for the purposes of
> discussion, I think the Definitions is an acceptable temporary location, as
> the “method” can be tweaked in one location without having to deal with
> churn in multiple locations of the document.
>
I do not support this redefinition of "Authorization Domain Name". I am
fully supportive of finding a better way to express this algorithm, but I
think this proposal, as it stands, is a net-negative due to introducing
significantly more (wholly unnecessary) complexity into the processing
algorithm. If you want to allow "chaining" methods, you can do so as .8
does, for example - but there is zero reason to support redefinition of
Authorization Domain Name. I think your separate reply to Tim on analysis
demonstrates this incorrectness, but rather than try to resolve that (while
preserving the ADN redefinition), it seems far simpler to implement,
review, and reason about to introduce this as a separate method.


> *2) I'm hoping you can actually document a more compelling case to allow
> arbitrary definition (and the complexity it entails) versus the existing
> methods that exist - such as CNAME.*
>
>
>
> I’m unsure if you’re referring to why I’m proposing “Method F” as a whole,
> or if you are taking issue with the DADL record’s ability to specify an
> arbitrary label, as opposed to mandating a specific label (such as
> “_pki-validation”).
>
I'm questioning whether "Method F" as a whole is necessary, given that .7
(or even a further tightening of .7) fully permits and defines what your
proposed "Method F" would entail. Thus, you are proposing a sub-class of an
existing method, which makes no sense.

The rationale you've given here further suggests that this is really just
the "fix the security holes in .7" - and thus it's unclear that something
as significant (and unnecessarily complex) as "Method F" is necessary to do
so.


> *3) I'm not overly keen on the specialization of the TXT record, as
> already mentioned. I'm sure simply floating this proposal to the DNSOP WG
> in the IETF can highlight the possible issues this can bring. For example,
> the syntax overlap can be a significant detriment through cross-protocol
> attacks on different semantic interpretations of the record*
>
>
>
> I agree that using TXT records is a hack, but unfortunately I do not see
> any other more preferable alternative with the current state of how CAA
> operates (see response #4 below). If we can make it work, I’d prefer to use
> CAA as opposed to TXT records.
>
>
>
> As for cross-protocol attacks, I believe that the rigid syntax required by
> the DADL record is an effective mitigation.
>
On this point, I think we disagree. The very nature of cross-protocol
attacks is not simply that you need to be 'rigid', but that every possible
conflatable protocol needs to be rigid as well. This is most easily
demonstrated by the ability to use HTTP for SMTP attacks, as they're both
text-based protocols with defined syntaxes, but can still be conflated
(which is why, for example, browsers block form posts to SMTP ports)

The use of TXT records is a structural deficiency we should be working to
correct - by avoiding them entirely - much in the same way the use of
arbitrary _ prefixes is that. The reasoning why we allow TXT records in the
first place was mentioned in the email to Doug, but that doesn't mean
they're a good thing, nor does it mean we can claim that they're mitigated
for cross-protocol attacks unless we consider every possible use of TXT
records.


> *4) I'm not sure I understand Tim's comment re: directionality - both this
> and CAA walk bottom-up*
>
>
>
> Perhaps I wasn’t clear in my previous email, but I was attempting to
> convey that the presence of any CAA record at a given domain halts
> tree-climbing. This makes CAA cumbersome to use to signal domain validation
> information, as domain owners need to repeat issue and issuewild property
> tags on every domain where they wish to specify allowed domain validation
> methods. This is not DRY (“don’t repeat yourself”) at all and cumbersome
> for domain owners.
>
I'm not really sure this argument makes sense. I'm hoping you can reason
more about the security properties here. Are you imagining that the DNS
operator of somedomain.example.com and example.com to be the same, but the
host operator to be different, thus the need to delegate certificate
management of somedomain.example.com to a different entity via _
pki-validation.somedomain.example.com that you would not otherwise delegate
via _pki-validation.example.com ? If so, I don't think that argument makes
sense for the use case claimed for Method 7/Method F here, in which the DNS
operation of somedomain.example.com is itself delegated (e.g. via CNAME or
DNS delegation). Because of CAA, if you cname somedomain.example.com to
another entity, that other entity controls the set of CAs being used - and
one would presume that other entity should equally control the
delegation/authorization (which, by being the target of the CNAME, they
already do).

Thus I don't think this is a good or necessary change, because it doesn't
logically fit with the use case or the CAA model.


> Shooting off the cuff here a bit, but perhaps to increase DRYness, a new
> CAA property tag is created which instructs CAA processors to store the
> encountered CAA Resource Record Set and then continue the tree-climbing
> process. Once the DNS root is reached or a non-empty Resource Record Set is
> encountered that doesn’t contain the “no halt” property tag, the
> concatenation of all Resource Record Sets is processed as a singular CAA
> Resource Resource Set. This would allow domain owners to define DV
> information (along with the “no halt” property tag) in CAA records (which
> may differ from that found at the Base Domain Name /parent nodes) but allow
> for a singular location to define allowed issuers (presumably at the Base
> Domain Name). Support for it by CAs could be optional, but domain owners
> can mandate support by setting the “critical” flag on the “no halt” record.
>
I think this is an unnecessary and detrimental change, in that it adds a
host of implementation complexity (which further affects the ability to
reason and use this, perhaps disastrously so) for a fairly abstract
principle (DRYness) without quantifiable metrics or definition, nor of the
relative cost that imposes on the system versus what this would impose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180425/848e08d2/attachment.html>