Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

+1, DNSSEC itself is susceptible to active attacks and needs a secure channel to protect from an active attacker. -Tiru From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of Ben Schwartz Sent: Saturday, October 28, 2017 9:34 PM To: Daniel Kahn Gillmor

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

An active attacker can drop DNS messages with DNSSEC records, set the CD bit in the DNS query, AD bit in the DNS response (see https://tools.ietf.org/html/rfc4035#section-7), clear the DNSSEC OK bit in the DNS query or strip the DNSSEC data from the DNS response to disable DNSSEC (Section

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: An active attacker can drop DNS messages with DNSSEC records The same attacker can block TLS to 8.8.8.8 set the CD bit in the DNS query, AD bit in the DNS response That will do nothing to validating DNS servers, as they don't use those

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon, 30 Oct 2017, Konda, Tirumaleswar Reddy wrote: draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement Just to be clear. DNSSEC provides authentication of data. TLS provides privacy of data. Both are needed so I am against this proposed change

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

Hiya, On 28/10/17 04:40, Daniel Kahn Gillmor wrote: > > Furthermore, i believe that the proposal in draft-11 of making DNSSEC > validation of metaqueries a MUST for the opportunistic profile is > *actively harmful* to the stated goal of the opportunistic profile > (i.e., "maximum chance of DNS

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

> On 28 Oct 2017, at 04:40, Daniel Kahn Gillmor wrote: > > Hey DPRIVE folks-- > > Apologies for the delay, and that this message is so long. I've tried > to reconstruct this discussion around > draft-ietf-dprive-dtls-and-tls-profiles-11 as best i can, and my > analysis

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon 2017-10-30 07:19:36 -0400, Paul Wouters wrote: > Just to be clear. DNSSEC provides authentication of data. TLS provides > privacy of data. Both are needed so I am against this proposed change > to remove DNSSEC validation as a requirement. DNSSEC is part of the > core DNS. It's not a

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Fri, Oct 27, 2017 at 11:40:15PM -0400, Daniel Kahn Gillmor wrote a message of 219 lines which said: > I do not believe that DNSSEC validation is warranted as a mitigation > against an active attacker in the context of an opportunistic > metaquery, I see the point

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote: > I really do think a description there of the trade-offs of DNSSEC > validation are warranted I agree that a discussion of the tradeoffs involved in DNSSEC validation of the opportunistic meta-query is warranted. I just come to a different

Re: [dns-privacy] Why is draft-ietf-dprive-dtls-and-tls-profiles still blocked?

On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote: > The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles > has a DISCUSS "This needs to be updated to indicate that the client > MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise > you're going to have

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote: On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote: if it ends up just being a MAY (although I would like to see SHOULD as a minimum for opportunistic). SHOULD validate, but with what failure mode? +1 to the question: we're talking

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

Hiya, On 30/10/17 15:42, Paul Hoffman wrote: > Having this document say, in essence, "you don't get opportunistic > encryption unless you add a DNSSEC validation stack" feels like a > regression to the original goals of this WG. I'm not sure that having a stack is such a barrier in reality.

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On 30 Oct 2017, at 6:11, Sara Dickinson wrote: I’d disagree that connecting to a server for which the meta-query response failed DNSSEC validation results in _just_ a loss of privacy for Opportunistic in this case. If the answer was BOGUS then it seems reasonable to assume the server is not

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

> On 30 Oct 2017, at 15:08, Daniel Kahn Gillmor wrote: > > On Mon 2017-10-30 13:11:41 +, Sara Dickinson wrote: >> I really do think a description there of the trade-offs of DNSSEC >> validation are warranted > > I agree that a discussion of the tradeoffs involved in

Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote: Date: Mon, 30 Oct 2017 11:08:35 From: Daniel Kahn Gillmor Cc: dns-privacy@ietf.org To: Sara Dickinson Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert