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 DNSSEC
validation requirement
On Mon
> 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 DNSSEC validation
> of t
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.
Requ
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 ab
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 inter
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
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 le
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 but it seems to me a small
> 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 follows. If i've misund
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 s
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 cherry.
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
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
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 https
On Oct 30, 2017, at 13:09, Konda, Tirumaleswar Reddy
wrote:
>
> +1, DNSSEC itself is susceptible to active attacks and needs a secure channel
> to protect from an active attacker.
What active attacks is DNSSEC vulnerable to?
And how does that not affect TLS?
Paul
>
> -Tiru
>
> From: dn
+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
Cc: dns-privacy@ietf.org
Su
16 matches
Mail list logo