Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-dnsoquic-10: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 10 March 2022 06:14 UTC

Return-Path: <kaduk@mit.edu>
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 B379E3A0831; Wed, 9 Mar 2022 22:14:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham 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 2bzn7C3LIedn; Wed, 9 Mar 2022 22:14:52 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 501EB3A082D; Wed, 9 Mar 2022 22:14:50 -0800 (PST)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22A6Ednu027726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Mar 2022 01:14:44 -0500
Date: Wed, 09 Mar 2022 22:14:38 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Christian Huitema <huitema@huitema.net>
Cc: The IESG <iesg@ietf.org>, dns-privacy@ietf.org, draft-ietf-dprive-dnsoquic@ietf.org, brian@innovationslab.net, dprive-chairs@ietf.org
Message-ID: <20220310061438.GX22457@mit.edu>
References: <164687680922.27252.2745356593117748500@ietfa.amsl.com> <e795b2df-1d57-10ff-4d85-cf381081d674@huitema.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e795b2df-1d57-10ff-4d85-cf381081d674@huitema.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/rcX39Gb91brqEcIC0s0_uJ9rOCc>
Subject: Re: [dns-privacy] Benjamin Kaduk's Discuss on draft-ietf-dprive-dnsoquic-10: (with DISCUSS and COMMENT)
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Addition of privacy to the DNS protocol <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: Thu, 10 Mar 2022 06:14:54 -0000

On Wed, Mar 09, 2022 at 09:17:52PM -0800, Christian Huitema wrote:
> Thanks for the pull request, Ben. Looking at it now.
> 
> On the 0RTT point: it is indeed possible for a server to not support 
> 0RTT at all, and if this is not clear, we should clarify.

Thanks for clarifying -- I've dropped the Discuss and we can look at ways
to clarify.

My first instinct would be to to add a new paragraph near the top of §5.5,
maybe as the second paragraph, that outlines server behavior in general,
somewhat analogous to what the first paragraph currently does.  This would
give us an opportunity to encourage servers to support session resumption
(IIRC it is not already required for the server to support it) as well as
to state that servers can choose to not enable 0-RTT.  I might even be able
to come up with some concrete text, but not before the telechat.

> I do have a concern about the interaction between "support for 0-RTT" 
> and "keep connections alive for a long time". If servers do not support 
> 0-RTT, clients have incentive to use artificial traffic and keep 
> connections alive, and that could be a lot of overhead for servers. But 
> people deploying servers can weight that among other factors, and not 
> supporting 0RTT is one of many possible choices.

That is an entirely reasonable concern to have!  But I agree with the
conclusion that ultimately it's a decision that needs to be made by people
deploying servers, and we just have to document the various considerations
as well as we can, so that they can weigh the factors according to their
individual situation.

-Ben