Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt

Ilari Liusvaara <ilariliusvaara@welho.com> Sun, 10 April 2022 16:23 UTC

Return-Path: <ilariliusvaara@welho.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 97AB83A15F0 for <dns-privacy@ietfa.amsl.com>; Sun, 10 Apr 2022 09:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 Y08_SAqsUJJz for <dns-privacy@ietfa.amsl.com>; Sun, 10 Apr 2022 09:23:26 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3b.welho.com [83.102.41.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80C8B3A006A for <dns-privacy@ietf.org>; Sun, 10 Apr 2022 09:23:25 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id EE0F318360 for <dns-privacy@ietf.org>; Sun, 10 Apr 2022 19:23:22 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id uzVE8KtP9fYw for <dns-privacy@ietf.org>; Sun, 10 Apr 2022 19:23:22 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id C261827B for <dns-privacy@ietf.org>; Sun, 10 Apr 2022 19:23:21 +0300 (EEST)
Date: Sun, 10 Apr 2022 19:23:21 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: dns-privacy@ietf.org
Message-ID: <YlMEecR9N92Ua3BK@LK-Perkele-VII2.locald>
References: <164667566033.16942.15407079409764144071@ietfa.amsl.com> <F923A397-81EA-4C6B-87C9-571168FBE6E1@sinodun.com> <87ilrgkjjs.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87ilrgkjjs.fsf@fifthhorseman.net>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/AVkXpAyAArJ97O-UrKs5Dezq6zo>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-unilateral-probing-00.txt
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: Sun, 10 Apr 2022 16:23:30 -0000

On Sun, Apr 10, 2022 at 09:08:39AM -0700, Daniel Kahn Gillmor wrote:
> 
> On Thu 2022-04-07 16:47:02 +0100, Sara Dickinson wrote:
> 
> > 3) The issue of signalling… I agree there is still work to do to mange
> > this. From this reading:
> 
> > - from a client perspective the concept of unilateral probing is
> > pretty clear. There is a defined behavior for direct probing, which
> > will be different from the behavior if 'external coordination' is
> > available.
> >
> > - however servers can't know for sure how the client discovered them
> > or how/if they are authenticating the connection. This document
> > doesn't prescribe a way to know that a server is 'only' doing
> > unilateral deployment and/or something else, hence the potential
> > future issues with signalling.
> >
> > - given this draft is Informational and is designed to enable
> > experiments I can't remember if there has already been discussion of
> > using an 'alternative' ALPN for this initial deployment? By that I
> > mean, use something like 'doq-p01’(DoQ probing 01) for these kind on
> > connections (in the same way I-D tagged ALPNs are used during protocol
> > development)? That way each side knows explicitly how to behave and
> > statements like "An authoritative DNS server that wants to handle
> > unilateral queries' would have clear meaning. Whilst this is taking
> > liberties with ALPN and may have already been dismissed as an option,
> > it does solve a number of problems in the short term and enable
> > negotiation and evolution. Just asking :-)
> 
> This is an interesting question: the proposal to play games with ALPN
> hasn't yet been raised to my knowledge.
> 
> Due to ALPN's transport in the clear for a normal TLS handshake, i'd be
> reluctant to endorse that use here.  I don't think we want a network
> observer to know which encrypted transports are opportunistic and which
> are due to signalled information.
> 
> I'm also trying to get my head around what such an indicator would be
> useful for.  Presumably the authoritative server would behave
> differently based on that indicator, but i'm having a hard time
> imagining what the authoritative server should do differently.  Is it
> just for statistics/accounting?  Can you explain what you think the
> purpose of such an indicator would be?

Perhaps there could be separate ALPNs for recursive and authoritative
DNS service, with no distinction if authoritative service is
opportunistic or not?



-Ilari