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 On Thu, May 30, 2019 at 4:17 PM Hugo Landau <[email protected]> wrote: > > > ---------------------------------------------------------------------- > > 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. -- 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 _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
