Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
Vladimír Čunát <vladimir.cunat+ietf@nic.cz> Fri, 01 November 2019 14:39 UTC
Return-Path: <vladimir.cunat+ietf@nic.cz>
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 3627C12086F for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 07:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.997
X-Spam-Level:
X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 BGhSUcrxcont for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 07:39:03 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 C65F512086E for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 07:39:02 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:fce0:91f8:a499:2d90] (unknown [IPv6:2001:1488:fffe:6:fce0:91f8:a499:2d90]) by mail.nic.cz (Postfix) with ESMTPSA id EE9A1140E95; Fri, 1 Nov 2019 15:38:59 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1572619140; bh=YH1myFrTHRYL4sC1wiH3ttLUKSvJaRXQDX2p6AlVDjI=; h=To:From:Date; b=QkIAzRTvVdBySdto0qYV/qUX6lFCmKj+qP7ROqrzzXlQ7xKWAs88hp0eWn3iGOPlf h+rfnFQVobq2Iu6RghtNiOXWSgb22gpz7wr4wjSBjjNFyTNSUAKsp+72mCcSeZvhlI f4PZt33AiDf7PG4M2Ozlf7KbYRGOjfhpDihA4C/s=
To: Eric Rescorla <ekr@rtfm.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>
References: <CAHbrMsDwDoTQN8Y5Zk7rSVepjwwyatEyAA6f0oJ9DESmAfHfXg@mail.gmail.com> <20191031211222.A6422DBC1C7@ary.qy> <CAH1iCiqYoXMZ0U3yt8AjUXyZVRdDnmHzSpHvYmg++ACZ-U6=zA@mail.gmail.com> <CABcZeBP-k23ZY=f6Lv5A+B+Z_4ar_9ea=G7O+KRriXNLUzKGqw@mail.gmail.com> <95e65176-0b80-fbe0-8409-11fada175c67@nic.cz> <CABcZeBPCMBDEGTpVULJgQEz_5Ddv27jayMxaW-fqXL3HQrqbyw@mail.gmail.com>
From: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Message-ID: <ad1f9fff-1c4e-a352-9f23-04473427e1e7@nic.cz>
Date: Fri, 01 Nov 2019 15:39:14 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.1
MIME-Version: 1.0
In-Reply-To: <CABcZeBPCMBDEGTpVULJgQEz_5Ddv27jayMxaW-fqXL3HQrqbyw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------9587682D2C494277C4FED613"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/pZnPCrUI_Unf27__eT35K1mHIjQ>
Subject: Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?
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: Fri, 01 Nov 2019 14:39:05 -0000
On 11/1/19 3:13 PM, Eric Rescorla wrote: > > Generally speaking, I believe it's fine to add assumptions about > DNSSEC > validation, if that makes the ADoT protocol "better" in some way. > (and > I expect it will) It seems that DNSSEC will be much easier than this > new stuff. > > > Easier for who? The advantage of transport security in this setting is > that the authoritative can just deploy it for all their users without > any interaction with the user. I don't follow you - where's the user interaction? To deploy DNSSEC, I click a checkbox in my registrar's UI. That's all. Actually, here in .cz you usually even need to make effort not to get DNSSEC. Or do you refer to the recursive resolver as "user"? Not even stubs (like Firefox) should communicate with authoritatives, so these still won't need to start caring about validating themselves, if that's the direction you mean. > By the way, I'm personally not yet 100% convinced by TLS and might > e.g. > add QUIC into consideration > > > Well, DoQ seems like an interesting direction, but I'm not sure what > you mean by > "not 100% convinced by TLS". Not convinced by the relatively long (first-time) handshakes; I see no other problem, and the overwhelming TLS deployment is a huge advantage (libs, bugs, tools). TLS just wasn't designed for sessions that only need to transport 1kB. Other options: I can't remember if DTLS can do a faster handshake (probably not), but over longer term QUIC will surely have larger deployment. DoH would cover both TLS and QUIC, but the http layer seems pointless here, and I can't see demand in this WG anyway. A specialized protocol might be even a better fit in terms of handshake and other properties (say DNSCrypt, DNSCurve or even a new one), but I *suspect* these paths wouldn't be worth it - another transport protocol just for DNS privacy. --Vladimir
- [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] DPRIVE Interim: 10/29 Allison Mankin
- Re: [dns-privacy] DPRIVE Interim: 10/29 tjw ietf
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Rob Sayre
- Re: [dns-privacy] DPRIVE Interim: 10/29 Eric Vyncke (evyncke)
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Paul Hoffman
- [dns-privacy] ADoT requirements for authenticatio… Paul Hoffman
- Re: [dns-privacy] ADoT requirements for authentic… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Hoffman
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Christian Huitema
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] DoT at the DNS root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Watson Ladd
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Alexander Mayrhofer
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ralf Weber
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Paul Wouters
- Re: [dns-privacy] ADoT requirements for authentic… Tony Finch
- Re: [dns-privacy] [EXTERNAL] Re: [Ext] Re: DPRIVE… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: DPRIVE Interim: 10/29 Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Livingood, Jason
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- [dns-privacy] ADoT deployment at the root Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Jim Reid
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] ADoT deployment at the root Ted Hardie
- Re: [dns-privacy] ADoT deployment at the root Warren Kumari
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] ADoT deployment at the root John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ben Schwartz
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Stephen Farrell
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Hollenbeck, Scott
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Eric Rescorla
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Vladimír Čunát
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Ted Hardie
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… Brian Dickson
- Re: [dns-privacy] [Ext] Re: ADoT requirements for… John R Levine
- Re: [dns-privacy] DPRIVE Interim: 10/29 Brian Haberman