Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

Christian Huitema <huitema@huitema.net> Tue, 20 August 2019 16:30 UTC

Return-Path: <huitema@huitema.net>
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 AC4BC120965 for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 09:30:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
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 GYq8Wa-S5loM for <dns-privacy@ietfa.amsl.com>; Tue, 20 Aug 2019 09:30:12 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 841F2120105 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 09:30:12 -0700 (PDT)
Received: from xse491.mail2web.com ([66.113.197.237] helo=xse.mail2web.com) by mx63.antispamcloud.com with esmtp (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1i071O-0003wL-Hr for dns-privacy@ietf.org; Tue, 20 Aug 2019 18:30:11 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 46Cbqh1GPvz9w3 for <dns-privacy@ietf.org>; Tue, 20 Aug 2019 09:30:08 -0700 (PDT)
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1i071M-0008T8-2J for dns-privacy@ietf.org; Tue, 20 Aug 2019 09:30:08 -0700
Received: (qmail 28654 invoked from network); 20 Aug 2019 16:30:07 -0000
Received: from unknown (HELO [IPv6:2607:fb90:b2a5:8c49:2c02:232:b997:17e]) (Authenticated-user:_huitema@huitema.net@[172.58.45.9]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <hmco@env.dtu.dk>; 20 Aug 2019 16:30:07 -0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <CAHbrMsBB1P7YVuXNUY4Gb1jiwjGMLxWnKWTtCxs6qHCL=DxEwg@mail.gmail.com>
Date: Tue, 20 Aug 2019 09:30:06 -0700
Cc: "Henderson, Karl" <khenderson@verisign.com>, "hmco@env.dtu.dk" <hmco@env.dtu.dk>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>
Content-Transfer-Encoding: quoted-printable
Message-Id: <7D57D07D-8ED5-4BF2-A4A8-263F80ACE6CB@huitema.net>
References: <6CD20313-147F-40A9-91D2-16F2E19A4B48@verisign.com> <19d1358f-52cf-6f67-f53f-7084c6c8c115@cs.tcd.ie> <B91A1CC7-9BF8-4406-A402-BA7E101F8E7F@verisign.com> <CAHbrMsBB1P7YVuXNUY4Gb1jiwjGMLxWnKWTtCxs6qHCL=DxEwg@mail.gmail.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
X-Originating-IP: 66.113.197.237
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.08)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0ZMJr/TGkEWvNJbVmORegSypSDasLI4SayDByyq9LIhV5tEUCvswVW6X Oug6cPDgSUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDwPzgJ2Ucltmld9WkfaJBY9Xt FNSzkMWnDricnMrpFJrdXjHV78ChDvEWxxQukZXdQVFPFt+4EqMnp4CTDhVg0lKlzDUUdXZXKiJE 9FAeBYpBbCpe79Kozx0nomzoHNuE/dtfRZzRO+BHduG/wGGv/w7GrRD93GuKsil0DsNlfaStdanO U07Z4oQbhfKrYy0P2DgAp0at4W1lubqSgAR5nJ0cRw78AMyqgpaL1PdpEt4pk7cjbWy91pm/jG4G U42zKLTFpngmCzMfOMV6XuhaobdAzbZabvf4+eAvvSn0D5YsJPkCw5CFSIcclHhCFNsjBr4UQT5O ZMr/oeXfpj/bf7wqyT5p50x81ZKcmzCu2U08Q0kRWzyh6FXaC2BHab5YrsibCyBrx+YtCB8oetqR inwCY8vmv+JqOVJamBHfOGVwjn7Xut/lXagsodd5qqODTFiwcpU4fyz75jxpU98RPGiH1Wgh6RAe nBR+licROGaPP+lj0BOmjSsRmMqNUhRCJjPcLb76KTPJkzQlABO0sIvlFDKeMMIgdFDaAHISg6mI 9kVgrP8d/S99xR9aHf3T0ryXeQDqqkgHDboVrOy1pkXw8BMIsfBCWTvqwtHGsGbsxBoFbdIyTZwD 0tTyhMSs9ZJfhUSh0wL/8ki568LmQ4aPmF/7MAKyW1Kb4FKGpjSqQCpwfQT3JXwqZ+Ex1ylzeLjJ gFCw7xM7edJ+hMzC4A2MtuoXMRfSG2WhEZRm53vZNUdtbfcA3ykFvd0aHYOC647lNwN4qOsSZg+f YhVZG3Fpf9P2WwOdPRT3EWlMd754CMBw7+ErSKQN7lw8ITGaNmGHCZF9ZXtfSxIkZLsbHZnckpWa LvahyBjmQxBKOzsmHW0N+NPiHPgn+dyxhvT1Z5EPOIlpyGKEA1x50oTQDUtseoetsROuM82YMzIj 8EU=
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/aWOFtETBeZK-OqIk9IAPsuV71Sw>
Subject: Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations
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: Tue, 20 Aug 2019 16:30:14 -0000

 

> On Aug 20, 2019, at 9:15 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> A similar approach cannot be applied to ADoT.  Instead, we must define a complete, secure, performant ADoT negotiation system inside the DNS.  Until we have such a system defined, ADoT is not possible (except in limited experiments).

We have a working example of such transition: using the alternate service indication in HTTP to transition to HTTP 2 or to QUIC. The key there is to consider the problem as a transition from old and insecure to new and secure and to effect that transition over time. Perform a regular query over UDP or TLS, obtain additional information that DoT or DoH could have been used, remember that for next time.

Yes, that means that the first transaction is not protected. But then if we delay transition many more transactions are also unprotected. I like the idea of a progressive transition without disruption.

-- Christian Huitema