Re: [dns-privacy] Adam Roach's No Objection on draft-ietf-dprive-bcp-op-08: (with COMMENT)

[Adam Roach <[e-mail]>]

Top-posting because I agree with the facts as you present them. I just 
reach a different conclusion based on these facts. To be clear, I think 
a belt-and-suspenders approach is generally preferable. I am merely 
suggesting that the "must" statement I cite may be stronger than is 
actually advisable given that such an approach is merely a small 
increment of security for protocols that are otherwise secured (e.g., 
HTTP, which is the example the document chooses), rather than the sole 
defense, as may be the case with other protocols.

My top-line suggestion here is to choose a different example than HTTP.

Secondary to that is a suggestion that the "must" statement really only 
makes sense when it is a sole counter-measure, and that a softer 
recommendation ("should") makes more sense otherwise.

These are non-blocking comments, so I'm going to reiterate that the WG 
can ignore them -- I just wanted to make sure they were considered. It 
would be nice to hear from other folks on the topic as well.

/a

On 2/6/20 11:57, Brian Dickson wrote:
>
>
> On Thu, Feb 6, 2020 at 9:31 AM Adam Roach <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 2/6/20 09:08, Adam Roach wrote:
>     >
>     > For the specific example chosen, it's been made pretty clear
>     over the
>     > years that at least the clients for the specific service you
>     cite have
>     > no interest in incurring this additional cost. If that's the
>     working
>     > group consensus, then I have no interest in over-riding it. But
>     > ignoring operational realities seems kind of ivory tower-ish, which
>     > feels like the kind of thing that undermines the general
>     credibility
>     > of the rest of the document.
>     >
>
>
> Could you please be more specific?
>
> When you say "for the specific service", do you mean DNSSEC?
>
> And do you mean the signing of DNS zones using DNSSEC, when you refer 
> to clients of that service?
>
> Perhaps you missed my microphone comments at the last IETF?
>
> Specifically that GoDaddy will be turning on DNSSEC for the vast 
> majority of its DNS hosting customers?
>
> This represents about 40% of the DNS zones on the Internet.
> (The exact time frame is not set in stone, but we expect this to be 
> done in the first half of 2020.)
>
> Given that this significantly alters the calculus, I don't think that 
> is a good enough reason to object in and of itself anymore.
>
> The other aspect of this is the asymmetry involved in the defenses 
> against impersonation:
>
>   * The choice to sign a DNS zone is under control of the zone owner
>   * The choice to deploy RPKI on routes (to protect against BGP
>     hijacking) is under control of the IP prefix holder
>   * Both methods rely on third parties to cooperate to achieve the
>     protections offered
>   * RPKI routing filters are now widely deployed, and RPKI
>     registrations are substantial
>   * The remaining issue is DNSSEC validation; many (most?) of the
>     public recursive operators do this already
>
> The logic should be, defend against all feasible attacks, rather than 
> justifying the non-defense in one area (DNSSEC for DNS) based on the 
> assertion that another area is not being defended (RPKI for BGP).
>
> Brian
>
>
>     I realize that my editing made one of the pronoun antecedents here go
>     away. The second sentence should have said something more like "If
>     keeping the current text is the working group consensus..."
>
>     /a
>