Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03

Benjamin Kaduk <kaduk@mit.edu> Mon, 23 December 2019 22:05 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67D8312022A; Mon, 23 Dec 2019 14:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 OEtr67NwFg2U; Mon, 23 Dec 2019 14:05:18 -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 79BD41201DB; Mon, 23 Dec 2019 14:05:18 -0800 (PST)
Received: from kduck.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 xBNM59oC001666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Dec 2019 17:05:12 -0500
Date: Mon, 23 Dec 2019 14:05:09 -0800
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sara Dickinson <sara@sinodun.com>
Cc: last-call@ietf.org, dns-privacy@ietf.org, draft-ietf-dprive-rfc7626-bis.all@ietf.org, secdir@ietf.org, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Message-ID: <20191223220509.GK35479@kduck.mit.edu>
References: <157504194893.4871.5551746255324168227@ietfa.amsl.com> <208AD30F-1213-4784-81FC-4AB76730CEC2@sinodun.com> <a02720cf-01b3-d61a-94d2-b3d0a399f107@cs.tcd.ie>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <a02720cf-01b3-d61a-94d2-b3d0a399f107@cs.tcd.ie>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/4-PnLiIr36XC0_g5aOVRu0xR_YI>
Subject: Re: [secdir] [dns-privacy] Secdir last call review of draft-ietf-dprive-rfc7626-bis-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Dec 2019 22:05:20 -0000

On Wed, Dec 18, 2019 at 02:00:45PM +0000, Stephen Farrell wrote:
> 
> Hiya,
> 
> On 18/12/2019 13:45, Sara Dickinson wrote:
> > 
> > 
> >> On 29 Nov 2019, at 15:39, Stephen Farrell via Datatracker <noreply@ietf.org> wrote:
> >>
> >> Reviewer: Stephen Farrell
> >> Review result: Ready
> > 
> > Hi Stephen, 
> > 
> > Thanks for reviewing (again)!
> > 
> >>
> >> I might not be the best reviewer for this one as I've read it a few times
> >> before. But anyway, I scanned the diff [1] with RFC7626 and figure it
> >> seems fine. 
> >>
> >> The only thing that occurred to me that seemed missing was to note
> >> that while the new privacy analysis in 3.5.1.1 is already complex, many
> >> systems are mobile and hence an analysis that ignores that won't be 
> >> sufficient. For a mobile device one really needs to analyse all of the 
> >> possible setups, and hence it's even harder to get to a good answer. 
> >> (It could be that that's elsewhere in the document but since I only 
> >> read the diff, I didn't see it:-)
> > 
> > There was a bit of discussion about this and the following text in 3.4.1 was added:
> > 
> > “ It is also noted that typically a device connected _only_ to a modern
> >    cellular network is
> > 
> >    o  directly configured with only the recursive resolvers of the IAP
> >       and
> > 
> >    o  all traffic (including DNS) between the device and the cellular
> >       network is encrypted following an encryption profile edited by the
> >       Third Generation Partnership Project (3GPP [2]).
> > 
> >    The attack surface for this specific scenario is not considered here."
> > 
> > Which hopefully covers this?
> 
> Not really, no. My point is that the analysis in 3.5.1.1
> doesn't encompass the fact that hosts are often (or even
> mostly) mobile and hence connect to many networks, and that
> the results of a privacy analysis related to DoT/DoH will
> likely differ for each of those networks, from the POV
> of the user or device owner, and even those two may not
> agree in some cases.
> 
> I don't believe that point is made in the document. But
> I'm ok that you and the ADs figure out if its needed or
> not.

I think some kind of treatment is needed, even if the extent of the
treatment might still be up for debate.

Sara: note that "mobile" here is used in the generic sense of "moving
around", not specific to a mobile or "cellular" pocket computer (aka
"phone").

(I also agree with Ekr that the considerations around 3GPP encryption
remain not great and would prefer to not rely on them.)

Thanks for raising these issues, Stephen and Ekr.

-Ben