[Acme] Warren Kumari's Discuss on draft-ietf-acme-caa-07: (with DISCUSS and COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-acme-caa-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-acme-caa/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Firstly, thank you for writing this -- I do however have some concerns around
Section "5.6.  Use with and without DNSSEC"

1: "Where a domain chooses to secure its nameservers using DNSSEC, the
authenticity of its DNS data can be assured, providing that a given CA makes
all DNS resolutions via an appropriate, trusted DNSSEC-validating resolver." A:
DNSSEC does *not* secure nameservers, it secures the DNS data itself (think
object security vs channel security) -- I'd suggest "When a domain is signed
using DNSSEC, the authenticity..." B: I'm confused what"appropriate" means in
"appropriate, trusted DNSSEC validating resolver" -- if it is trusted I'd
assume it is appropriate? Please explain. C: The way that a resolver signals to
a client that it has performed validation (and that the answer validated) is to
set a single bit (AD) in the response - this is obviously something which
should not be relied upon for security sensitive stuff - I'd strongly suggest
that i) there be some text around getting the responses from the resolver to
the CA machine securely (e.g over DNS-over-TLS), or better yet ii) that the CA
machine itself do the DNSSEC validation - there are many libraries / systems to
make this easy, e.g Stubby, libunbound, etc.

2: "A domain can use this property to protect itself from the threat posed by a
global adversary capable of performing man-in-the-middle attacks, ..." A: What
is the purpose of "global" in "global adversary" -- I'm assuming it is trying
to communicate something important here, but how is this different to a "local"
adversary capable of performing man-in-the-middle attacks?

3: " Use of the "accounturi" or "validationmethods" parameters does not confer
additional security against an attacker capable of performing a
man-in-the-middle attack against all validation attempts made by a given CA
which is authorized by CAA where:
   1.  A domain does not secure its nameservers using DNSSEC, or
   2.  That CA does not perform CAA validation using a trusted
   DNSSEC-validating resolver.
Moreover, use of the "accounturi" or "validationmethods" parameters does not
mitigate against man-in-the-middle attacks against CAs which do not validate
CAA records, or which do not do so using a trusted DNSSEC-validating resolver,
..."

Can this document simply say: "When using this method, CA's MUST use a
DNSSEC-validating resolver"? -- it will a: make the protocol more secure and b:
simplify a bunch of the document and c: isn't a large burden. During the
so-called "DNSpionage" incident, it seems that a specific CA was chosen because
it didn't do DNSSEC validation (or, perhaps would try validate, but would still
issue if DNSSEC validation failed) -- see:
https://mailman.nanog.org/pipermail/nanog/2019-March/099852.html


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you again for writing this, and apologies for not balloting earlier -
I've got a cold and am behind on my IETF work.