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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Wed, 29 May 2019 12:40:42 -0700

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.

---

From: Hugo Landau <[email-masked]>
Date: Thu, 30 May 2019 21:17:27 +0100

> 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..."
Done.

> 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.
Extraneous word removed.

> 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.
Done.

Added:

  A CA supporting the "accounturi" or "validationmethods" parameters MUST
  perform CAA validation using a trusted, DNSSEC-validating resolver.

  "Trusted" in this context means that the CA both trusts the resolver
  itself and ensures that the communications path between the resolver and
  the system performing CAA validation are secure. It is RECOMMENDED that
  a CA ensure this by using a DNSSEC-validating resolver running on the
  same machine as the system performing CAA validation.

> 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?
Added a paragraph introducing this concept.

The first two paragraphs now read

  The "domain validation" model of validation commonly used for
  certificate issuance cannot ordinarily protect against adversaries who
  can conduct global man-in-the-middle attacks against a particular
  domain. A global man-in-the-middle attack is an attack which can
  intercept traffic to or from a given domain, regardless of the origin or
  destination of that traffic. Such an adversary can intercept all
  validation traffic initiated by a CA and thus appear to have control of
  the given domain.

  Where a domain is signed using DNSSEC, the authenticity of its DNS data
  can be assured, providing that a given CA makes all DNS resolutions via
  a trusted DNSSEC-validating resolver. A domain can use this property to
  protect itself from the threat posed by an adversary capable of
  performing a global man-in-the-middle attack against that domain.

> https://mailman.nanog.org/pipermail/nanog/2019-March/099852.html
Done, see above.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 30 May 2019 22:47:31 +0000

Awesome - thank you for addressing these so quickly, and in the spirit
with with they were intended.

I'm clearing my DISCUSS.

Thanks again,
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf