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

[Hugo Landau <[e-mail]>]

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


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


> 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
Done, see above.