Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
Paul Wouters <paul@nohats.ca> Sun, 24 May 2020 21:36 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A24FE3A0C66 for <dns-privacy@ietfa.amsl.com>; Sun, 24 May 2020 14:36:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuNEfod_f_ZZ for <dns-privacy@ietfa.amsl.com>; Sun, 24 May 2020 14:36:20 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B61E63A0C63 for <dns-privacy@ietf.org>; Sun, 24 May 2020 14:36:19 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 49VYSb5Lv5zLcR; Sun, 24 May 2020 23:36:15 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1590356175; bh=kbQKvMCxqloER+QX5ksSM54XVLlekNps3vbwXmbIsoY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hoyLLisDrG+/fgNmLLUq+KHWzEq87gIMfY9Qbbb0HAsULoVfcK9ng93Q5DhTT6+x7 JofcqHooNJb1aDBSO0WG7n7Jw+BQ1vDd3BX9l63cQGAPueJtITREvqSXYL0lAImRQe +nR8Pq39cH+tNMbIs51GtEZyNegmnr2lYwPw9dck=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 5Y_V5tkPSDTv; Sun, 24 May 2020 23:36:14 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sun, 24 May 2020 23:36:14 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id 592096020EF2; Sun, 24 May 2020 17:36:13 -0400 (EDT)
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5538066B7C; Sun, 24 May 2020 17:36:13 -0400 (EDT)
Date: Sun, 24 May 2020 17:36:13 -0400
From: Paul Wouters <paul@nohats.ca>
To: Peter van Dijk <peter.van.dijk@powerdns.com>
cc: dns-privacy@ietf.org
In-Reply-To: <77f7a9c38c6bd0a059679a7ab3027b4da9005512.camel@powerdns.com>
Message-ID: <alpine.LRH.2.21.2005241710490.10453@bofh.nohats.ca>
References: <158987990316.29446.4343920282978207647@ietfa.amsl.com> <a15e2d1df86820f2483516662d3712d8a60161cd.camel@powerdns.com> <alpine.LRH.2.21.2005191134560.13722@bofh.nohats.ca> <ec6bc9248179a9ab56ea490f82b14c7e90ffe819.camel@powerdns.com> <alpine.LRH.2.21.2005241222410.4172@bofh.nohats.ca> <77f7a9c38c6bd0a059679a7ab3027b4da9005512.camel@powerdns.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/jsxpISjrBQiyGM3sKuc0Vdy9io8>
Subject: Re: [dns-privacy] [Fwd: New Version Notification for draft-vandijk-dprive-ds-dot-signal-and-pin-00.txt]
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 May 2020 21:36:22 -0000
On Sun, 24 May 2020, Peter van Dijk wrote: > On Sun, 2020-05-24 at 13:43 -0400, Paul Wouters wrote: >> But I also don't see the gains of abusing DNSKEY, because you already >> need to query the DNSKEY of the domain to get the pesudeo-DNSKEY key, >> and then you already lost your privacy. > > The draft says 'The pseudo DNSKEY record MUST NOT be present in the > zone.' What can we add to the text to make it clear that no query is > sent to the zone's name servers -until- their TLS key has been > verified? You confused me with "pseudo DNSKEY record". You meant to say "pseudo DS record". Now it makes more sense that our suggestions are a lot more similar then I originally understood. The draft currently has: The pseudo DNSKEY record MUST contain Base64 encoded [...] The pseudo DNSKEY record MUST NOT be present in the zone. Also, instead of showing openssl commands, explain to the reader the process of the resolver. What does it fetch, when does it fetch it, what information is extracted and used. Your draft also state: The pseudo DNSKEY type can be used in CDNSKEY and CDS (as defined in [RFC7344]) records. These records MAY be present in the zone. I think that should be a MUST, not a MAY. Or else a rogue parent inserting DS records to MITM the TLS cannot be detected. >> Conveying that you can do DoT using DS can only really be done by >> overloading the record type. > > Which field do you mean by 'the record type'? We chose the algorithm > field for it. I meant key tag. We have seen issues in the past with both resolver behaviour with unknown algorithms and registries limiting their drop down menus for DS components to only valid algorithms. I thought using keytag 0, which cannot happen normally, would allow you to leave algorithm and other values more real. >> If we don't want to hard fail, then I think we should just >> drop this draft and use opportunistic. > > This draft, that signals and key-pins, with hard failure, would not > prevent an opportunistic draft/RFC to also exist. Once the document gets further along, a Security Considerations section is needed to explain the details of pinning and how it interacts with TLS level pinning. >> If we want to offer hard fail, >> then some draft is still useful. > > Why not this draft then? :) Now I understand data is in the DS record, perhaps it can. It does all depend on whether we want to add limiting on/off signaling in the DS record only, or if we really want to stuff TLS public keys into the DS. I'm still not convinced of the latter, but might be persuaded. >> I would use the keytag record set to 0 to mean this DS record is not >> a real DNSKEY but "something else". > > This will require changes in registry software all over the world, or > some hack . I'm not saying that's prohibitive, but our draft is the way > it is because this is one of the many hurdles we wanted to avoid. A similar problem will happen for new algorithms. >>> Also, as Petr pointed out, our DNSKEY/DS-based proposal does not >>> involve additional queries and thus roundtrips; as far as I can >>> imagine, anything using TLSA would need extra queries. >> >> I don't believe a working solution cannot be allowed to introduce an >> extra roundtrip. > > I also do not believe that, but it's nice that we can do without the > extra roundtrip anyway! I'd really like to get the security and threat model cleared up before making decisions about 1 RTT. For instance, protection against a rogue parent is not something the draft currently tries to protect against. Paul
- [dns-privacy] [Fwd: New Version Notification for … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Mikael Abrahamsson
- Re: [dns-privacy] [Fwd: New Version Notification … Jeremy Harris
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Christian Huitema
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ondřej Surý
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Tony Finch
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Stephen Farrell
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Shumon Huque
- Re: [dns-privacy] [Fwd: New Version Notification … Eric Rescorla
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Eric Rescorla
- Re: [dns-privacy] [Fwd: New Version Notification … Ben Schwartz
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Petr Špaček
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Tony Finch
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Paul Wouters
- Re: [dns-privacy] [Fwd: New Version Notification … Christian Huitema
- Re: [dns-privacy] [Fwd: New Version Notification … Peter van Dijk
- [dns-privacy] re-evaluation of the draft, was Re:… Paul Wouters
- Re: [dns-privacy] re-evaluation of the draft, was… Robin Geuze
- Re: [dns-privacy] re-evaluation of the draft, was… Shumon Huque
- Re: [dns-privacy] re-evaluation of the draft, was… Peter van Dijk
- Re: [dns-privacy] re-evaluation of the draft, was… Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … John Levine
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] re-evaluation of the draft, was… Paul Wouters
- Re: [dns-privacy] NS names, was re-evaluation of … Christian Huitema
- Re: [dns-privacy] re-evaluation of the draft, was… Peter van Dijk
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Paul Wouters
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Bill Woodcock
- Re: [dns-privacy] NS names, was re-evaluation of … Shumon Huque
- Re: [dns-privacy] NS names, was re-evaluation of … Bill Woodcock
- Re: [dns-privacy] NS names, was re-evaluation of … John R Levine
- Re: [dns-privacy] NS names, was re-evaluation of … Brian Dickson
- Re: [dns-privacy] bootstrapping NS names, was re-… John Levine
- Re: [dns-privacy] bootstrapping NS names, was re-… Brian Dickson
- Re: [dns-privacy] bootstrapping NS names, was re-… John R Levine