Re: [dns-privacy] [Ext] Re: ADoT requirements for authentication?

Eric Rescorla <ekr@rtfm.com> Fri, 01 November 2019 15:29 UTC

Return-Path: <ekr@rtfm.com>
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 68FEC120903 for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 GXMVQM1d-uWc for <dns-privacy@ietfa.amsl.com>; Fri, 1 Nov 2019 08:29:45 -0700 (PDT)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5A2C1208F9 for <dns-privacy@ietf.org>; Fri, 1 Nov 2019 08:29:44 -0700 (PDT)
Received: by mail-lj1-x232.google.com with SMTP id t5so10674893ljk.0 for <dns-privacy@ietf.org>; Fri, 01 Nov 2019 08:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CptS8cHia/u2kmlyfxjRRSF7JeFk7FPhr6sEwst8NR0=; b=EBqMvQ4OnOkNjC7Cy4wElJjPmWrPWZeATuYnJbpinZ27hr+9bv3rssDx0Uh18ufRpT 5Yf9/7H7FtA9QCeV1ZoZSS7CGrBYasexkSqDKpoRnsmSSj3CPpMnXL7VA3B+dyRaIoFt BVw5JIsaqn4iJD/iYckOvlP6Qtxeq+jFP+4I30yypJbYb0BF6k2GxjydHYEtNUPBmpu3 6aT+wUTCYys/Dx9rkxIVGrSC60CW3Z3owT0V16cQMKMFWmqtQiHCdndRW2xKcfct/KVa NEv1rqo338gQrKoPlVI61LH0bjP1FIceQKfhCXnsmWS0Glu3ZBuEmKgGfHcGaMbeUM1H FfYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CptS8cHia/u2kmlyfxjRRSF7JeFk7FPhr6sEwst8NR0=; b=SAASCbuh2nZCANrD0O2L2DbAS47nV2ArIeJ4dYwjDt0gqUw6CnarSK2mn7eB40ar95 oj1yR2IrRyLACch6f7RrnqFfUCsfx+O13hi/vy4oMmFqs10fVBi0f4UVdgdZUUzUVLnr GWDbH0jYDoNeiDSavBRu11WcS+hBE5IsiWti0F/VS1YSLhzD9OWlWHJLIgw7ogmqOu9K PyxyAhutxYQK/XeGjKWV4K0ZiiRf4KPx9netsdqOUGqT2TbIySmAq50ruN6wU4sc/Dx8 MTkxaraD8hDjfjm5ipCOmES/HVPZwG3asQjmJWcsrFEUcgr5M/lZswmK6HOF4fziobmq rNYw==
X-Gm-Message-State: APjAAAVCjH0FDcmW8hn/i2+ZAtsx7HHyMm4QjxqBno1NzOhBMQK/wMxf IfIPh/dU/jQdqRXid3DyxyiBM8PORZdQDV5D8CQfcqzo
X-Google-Smtp-Source: APXvYqyZrzjSCj4YZ71B6NHj9KjgZX/gsPENC9lZQZakOXCzFOHeWGHR4E2pmPxELfBFNun4HIbNfFyw9EmofWw7F3k=
X-Received: by 2002:a05:651c:10c:: with SMTP id a12mr8633158ljb.93.1572622182980; Fri, 01 Nov 2019 08:29:42 -0700 (PDT)
MIME-Version: 1.0
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> <ad1f9fff-1c4e-a352-9f23-04473427e1e7@nic.cz>
In-Reply-To: <ad1f9fff-1c4e-a352-9f23-04473427e1e7@nic.cz>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 01 Nov 2019 08:29:06 -0700
Message-ID: <CABcZeBPOALwZPOUEYnC_GNJJsunyWXfcaYO_3WoTMwE26FZS+A@mail.gmail.com>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Cc: "dns-privacy@ietf.org" <dns-privacy@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000953d0905964aa2ae"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/nKj0fdHs6FLs_5OaNSeVHKRkMXo>
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 15:29:48 -0000

On Fri, Nov 1, 2019 at 7:39 AM Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
wrote:

> 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"?
>

Sorry, I mean the domain owner.



> 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.
>

QUIC and DTLS  have the same handshake performance. TLS has one more round
trip because of the TCP round trip. If you want something faster, you need
to have the public key of the server in the record pointing to it so that
the client can send in 0-RTT the first time.

-Ekr