Re: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)

Roman Danyliw <rdd@cert.org> Thu, 06 May 2021 12:23 UTC

Return-Path: <rdd@cert.org>
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 EA5573A203D; Thu, 6 May 2021 05:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 2KkSqQ_BKeZT; Thu, 6 May 2021 05:23:38 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 6C2CB3A203E; Thu, 6 May 2021 05:23:37 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146CNZja011772; Thu, 6 May 2021 08:23:35 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 146CNZja011772
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1620303816; bh=/7ddIaUZkVrpeGOmLlR3eTj6TzjJuQQ2rCojp5tLaZg=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=PHi6k+3gx95ehRGvM07lNoXi3vvoR/bJ8XldpWEHMcfctg6fl42pPGTAi0wKxDOAn yFv0NEAfL/repGQX/jJKqrHyDBQIiDaHDGUq4gCcI9okRETNVpW7B3UKfSaRCGPfyD SEbn3R12JJUszmrAwFatlraJT4Zlqa04AVgfxAPc=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146CNYMn008722; Thu, 6 May 2021 08:23:34 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 6 May 2021 08:23:33 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%21]) with mapi id 15.01.2242.008; Thu, 6 May 2021 08:23:33 -0400
From: Roman Danyliw <rdd@cert.org>
To: Sara Dickinson <sara@sinodun.com>
CC: "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-dprive-xfr-over-tls@ietf.org" <draft-ietf-dprive-xfr-over-tls@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
Thread-Index: AQHXQS6jlhYbbvPZNkeCqmtIOAjZOKrWgYaA///dxIA=
Date: Thu, 6 May 2021 12:23:32 +0000
Message-ID: <4ee9b135c27c49f0b587ac544d409e3f@cert.org>
References: <162016464323.21297.9629553981279271609@ietfa.amsl.com> <9D6A2244-45F1-4073-90D5-3C0A8F027ECD@sinodun.com>
In-Reply-To: <9D6A2244-45F1-4073-90D5-3C0A8F027ECD@sinodun.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.201.86]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/sp2dQMEaLKpLvYEX3O93rOUX6X4>
Subject: Re: [dns-privacy] Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11: (with COMMENT)
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: Thu, 06 May 2021 12:23:44 -0000

Hi Sara!

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of Sara Dickinson
> Sent: Thursday, May 6, 2021 6:13 AM
> To: Roman Danyliw <rdd@cert.org>
> Cc: tjw.ietf@gmail.com; dns-privacy@ietf.org; The IESG <iesg@ietf.org>rg>; draft-
> ietf-dprive-xfr-over-tls@ietf.org; dprive-chairs@ietf.org
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11:
> (with COMMENT)
> 
> 
> 
> > On 4 May 2021, at 22:44, Roman Danyliw via Datatracker <noreply@ietf.org>
> wrote:
> >
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-dprive-xfr-over-tls-11: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-dprive-xfr-over-tls/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ———————————————————————————————————
> 
> Hi Roman,
> 
> Many thanks for the review.
> 
> >
> > Section 1.  s/can make reconnaissance trivial/can make reconnaissance
> > and attack targeting easier/
> 
> Yes.
> 
> >
> > Section 1.  Per “… zone walking is now possible with NSEC3 due to
> > crypto-breaking advances”, a reference here would be helpful.
> 
> Agreed and requested by another reviewer - let me dig a good one out.
> 
> >
> > Section 1.  As far as I can tell the work on draft-vcelak-nsec5 has
> > not been adopted and the draft is expired.  Perhaps this should be
> > signaled via s/This has prompted further work on an alternative
> > mechanism/This promoted work on an alternative mechanism/
> 
> That seems reasonable.

Thanks for all of the above edits.

> >
> > Section 1.  Per “It is noted that in all of the common open source
> > implementations …”, as this is a point in time assessment, it would be
> > helpful to at least mention parenthetically the
> > implementations/version numbers assessed informally for this conclusion.
> 
> Another review suggested just adding “(at the time of writing)” to qualify that
> statement. Would that be enough (there are at least 5 implementations we
> could name)?

That works for me.

> >
> > Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.
> 
> “must therefore accept”?
>
> >
> > Section 4.
> >
> >   The threat model does not, however, consider the existence of a zone,
> >   the act of zone transfer between two entities, nor the identities of
> >   the nameservers hosting a zone
> >
> > To further document the assumptions, consider adding that this threat
> > model doesn’t consider/protect the mechanisms to decide on triggering
> > the zone transfer (e.g., protecting NOTIFY messages from an active
> > attacker)
> 
> Thats a reasonable point - I’ll add it. FYI - some operators do protect the NOTIFY
> with a TSIG for _some_ added protection.
>
> >
> > Section 6.2.  Per “However it is noted that most widely used open
> > source authoritative nameserver implementations (including both [BIND]
> > and [NSD]) do IXFR using TCP by default in their latest releases”, as
> > this document ages, “latest release” may not be meaningful.  Consider
> > providing a version number for [BIND] and [NSD].
> 
> Yes - that makes sense here.

Thanks.

> >
> > Section 8.4 and 10.4.  As already mentioned by Martin and John -- It
> > seems like a strong statement to say that IP ACLs are in the same
> > class of “channel authentication” as mTLS.
> 
> Hopefully addressed in the thread with Ben.

No problem.  I know a number of us made a related or identical comment.  I'll follow along in the DISCUSS made by Ben.

> >
> > Section 8.8.1.  It’s difficult to assess how effective this notional
> > padding approach would be for providing traffic analysis protection.
> > A few thoughts on the existing text realizing the details are out of scope:
> >
> > -- Does padding for AXoT need to be coordinated with the padding on IXoT?
> 
> I think that any zone that uses IXoT and pads would also always apply AXoT
> padding (because IXoT can fall back to AXoT). It would expect the draft on the
> specific padding policy would address that in more detail.
> 
> >
> > -- Is keeping state required to ensure that padding provides the
> > appropriate obfuscation over time?
> 
> Interesting question. Are you thinking about AXoT where the zone could e.g.
> grow then shrink? If so, that does seem like a good idea (again - input for the
> follow up padding policy draft - thanks!).

Exactly. Changes in sizes would be a prime traffic analysis metric.  This obfuscation would have to be consistently maintained to provide protection (to the degree that this obfuscation is robust) against a persistent observer who can take multiple measurements at different points in time.

With this comment and the one above it, I appreciate there is a fine line between balancing what's out of scope for a future, detailed specification; and adding design considerations or cautions in a notional architecture specified here.  I leave it to you and the rest of author team to assess the right balance as these were just (optional) ballot comments.

Regards,
Roman

> Thanks and regards
> 
> Sara.