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

Allison Mankin <allison.mankin@gmail.com> Thu, 06 May 2021 12:46 UTC

Return-Path: <allison.mankin@gmail.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 BD36F3A214A; Thu, 6 May 2021 05:46:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.098
X-Spam-Level:
X-Spam-Status: No, score=-0.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_DOTEDU=1.999] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3aFoxu78vXVn; Thu, 6 May 2021 05:46:12 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 50C063A212E; Thu, 6 May 2021 05:46:12 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id n15so1379599edw.8; Thu, 06 May 2021 05:46:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=A9iKnb/cJc3oZwd9EAzBjWHqp/Sqla/6/E6XHn2BfXU=; b=VcsFL2U0DmDdCiuNVbISjqWg2HagbnHcqHpS0V5LfZMU4bkQUg/209cYN6nRxyI9nl uCjx5PbzZ6xmg9jJZOLVmgU6Iq+zENs4DTGcI+wV5tV35TphWFXkC8w9si/+4BF01nFe ZRvddYsnCbHrUVD5q5+apA7UMTHnATBci8fYN/xCPOTjTDlAIckki6W0t7VX1/IFwOcq awZ7zVmw8RdADOay6OOaszCesEsi6JOJFolnhPKI9iRlrU4DA112Y2T8ZE5PcPvwW6mx 84tUQcKVXneBcJBAyvmgq9UaO8Azc0WOrN00VpE2+X9r41vo3+28AVhnoCZuWuoK5Lqw vMSA==
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=A9iKnb/cJc3oZwd9EAzBjWHqp/Sqla/6/E6XHn2BfXU=; b=DPKCz5jrwWcQBH6A//+y0voIDTb8/Zv8nqXd8rYV9tlF8klbeDCDF6+Ndd/2a2R6Fz nHqu4bFglh7fiRhpFkZdglYtEyXMRTs3NQoKL8pBGKLb29jFa9QO/QI338zZSp4pczO0 jiBn5fJznYEkVKQh4hScjMAn0e70sitzD0BF7S+E/wnS7tDJVjNUq6JF8iabehsKuRTF JjFAJVSyvbfbuJXxSLbWiJ2zeuIWwQA/ML1yM5tdguQOQxUefNgN43xxzzZfLoJ+ql/s 0AK0SfdL4igk8Paz823uufiBMarUgVkaqtLqGTqowroongIk4gEKnjqyeCznaJT/OZGd ss0w==
X-Gm-Message-State: AOAM530FfHCQtKvBrzAREunPEfgsKNXBCt4hnNg5PHaYg8QdQNuqtPOP t2UerYF8kqf+jEhd++zYjX0Nv6emij4IPadCK9Q0UEqKjFc=
X-Google-Smtp-Source: ABdhPJwLZxSD+YaDr13dTv15HofVnpc0BppHi8E3AzxG0i49rETV1Le+7oPF1Yql8QRyFUiChuUD71IT63pj5hnMQ8U=
X-Received: by 2002:a50:c34a:: with SMTP id q10mr4943234edb.346.1620305169673; Thu, 06 May 2021 05:46:09 -0700 (PDT)
MIME-Version: 1.0
References: <162016464323.21297.9629553981279271609@ietfa.amsl.com> <9D6A2244-45F1-4073-90D5-3C0A8F027ECD@sinodun.com> <4ee9b135c27c49f0b587ac544d409e3f@cert.org>
In-Reply-To: <4ee9b135c27c49f0b587ac544d409e3f@cert.org>
From: Allison Mankin <allison.mankin@gmail.com>
Date: Thu, 6 May 2021 08:45:58 -0400
Message-ID: <CAP8yD=tRWoF1DnWa5TBNTnhJx4VQ_4R1R5V7yJPKUTotAz74oQ@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: Sara Dickinson <sara@sinodun.com>, The IESG <iesg@ietf.org>, "dns-privacy@ietf.org" <dns-privacy@ietf.org>, "dprive-chairs@ietf.org" <dprive-chairs@ietf.org>, "draft-ietf-dprive-xfr-over-tls@ietf.org" <draft-ietf-dprive-xfr-over-tls@ietf.org>, "tjw.ietf@gmail.com" <tjw.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000010f19b05c1a8b2a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/iqDeOZr-gbiG7KHz3Lt2zxQyuuU>
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:46:24 -0000

Hi Roman and Sara,

Here is a good reference for the vulnerability of NSEC3:

https://www.cs.bu.edu/~goldbe/papers/nsec3attacks.pdf


On Thu, May 6, 2021 at 08:23 Roman Danyliw <rdd@cert.org> wrote:

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