From nobody Thu May 6 05:46:29 2021 Return-Path: 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 Date: Thu, 6 May 2021 08:45:58 -0400 Message-ID: To: Roman Danyliw Cc: Sara Dickinson , The IESG , "dns-privacy@ietf.org" , "dprive-chairs@ietf.org" , "draft-ietf-dprive-xfr-over-tls@ietf.org" , "tjw.ietf@gmail.com" Content-Type: multipart/alternative; boundary="00000000000010f19b05c1a8b2a3" Archived-At: 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 12:46:24 -0000 --00000000000010f19b05c1a8b2a3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 wrote: > Hi Sara! > > > -----Original Message----- > > From: iesg On Behalf Of Sara Dickinson > > Sent: Thursday, May 6, 2021 6:13 AM > > To: Roman Danyliw > > Cc: tjw.ietf@gmail.com; dns-privacy@ietf.org; The IESG ; > 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: > > > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94 > > > > 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 =E2=80=9C=E2=80=A6 zone walking is now possible with = NSEC3 due to > > > crypto-breaking advances=E2=80=9D, 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 =E2=80=9CIt is noted that in all of the common open s= ource > > > implementations =E2=80=A6=E2=80=9D, as this is a point in time assess= ment, it would be > > > helpful to at least mention parenthetically the > > > implementations/version numbers assessed informally for this > conclusion. > > > > Another review suggested just adding =E2=80=9C(at the time of writing)= =E2=80=9D to > qualify that > > statement. Would that be enough (there are at least 5 implementations w= e > > could name)? > > That works for me. > > > > > > > Section 1. Editorial. =E2=80=9C=E2=80=A6 must cater for accepting = =E2=80=A6=E2=80=9D doesn=E2=80=99t parse > for me. > > > > =E2=80=9Cmust therefore accept=E2=80=9D? > > > > > > > > Section 4. > > > > > > The threat model does not, however, consider the existence of a zon= e, > > > the act of zone transfer between two entities, nor the identities o= f > > > the nameservers hosting a zone > > > > > > To further document the assumptions, consider adding that this threat > > > model doesn=E2=80=99t consider/protect the mechanisms to decide on tr= iggering > > > the zone transfer (e.g., protecting NOTIFY messages from an active > > > attacker) > > > > Thats a reasonable point - I=E2=80=99ll add it. FYI - some operators do= protect > the NOTIFY > > with a TSIG for _some_ added protection. > > > > > > > > Section 6.2. Per =E2=80=9CHowever 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=E2= =80=9D, as > > > this document ages, =E2=80=9Clatest release=E2=80=9D may not be meani= ngful. 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 =E2=80=9Cchannel authentication=E2=80=9D 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=E2=80=99s difficult to assess how effective this n= otional > > > 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 protectio= n > (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 specificatio= n; > 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. > > --00000000000010f19b05c1a8b2a3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Roman and Sara,

Here is a good reference for the vulnerability of NSEC3:
=


On Thu, May 6, 2021 at 08:23 Roman D= anyliw <rdd@cert.org> wrote:
<= /div>
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@g= mail.com; dns= -privacy@ietf.org; The IESG <iesg@ietf.org>; 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 cu= t
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/stateme= nt/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.ietf.o= rg/doc/draft-ietf-dprive-xfr-over-tls/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2= =80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80= =94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94=E2=80=94= =E2=80=94=E2=80=94=E2=80=94
>
> Hi Roman,
>
> Many thanks for the review.
>
> >
> > Section 1.=C2=A0 s/can make reconnaissance trivial/can make recon= naissance
> > and attack targeting easier/
>
> Yes.
>
> >
> > Section 1.=C2=A0 Per =E2=80=9C=E2=80=A6 zone walking is now possi= ble with NSEC3 due to
> > crypto-breaking advances=E2=80=9D, a reference here would be help= ful.
>
> Agreed and requested by another reviewer - let me dig a good one out.<= br> >
> >
> > Section 1.=C2=A0 As far as I can tell the work on draft-vcelak-ns= ec5 has
> > not been adopted and the draft is expired.=C2=A0 Perhaps this sho= uld 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.=C2=A0 Per =E2=80=9CIt is noted that in all of the comm= on open source
> > implementations =E2=80=A6=E2=80=9D, as this is a point in time as= sessment, it would be
> > helpful to at least mention parenthetically the
> > implementations/version numbers assessed informally for this conc= lusion.
>
> Another review suggested just adding =E2=80=9C(at the time of writing)= =E2=80=9D to qualify that
> statement. Would that be enough (there are at least 5 implementations = we
> could name)?

That works for me.

> >
> > Section 1.=C2=A0 Editorial.=C2=A0 =E2=80=9C=E2=80=A6 must cater f= or accepting =E2=80=A6=E2=80=9D doesn=E2=80=99t parse for me.
>
> =E2=80=9Cmust therefore accept=E2=80=9D?
>
> >
> > Section 4.
> >
> >=C2=A0 =C2=A0The threat model does not, however, consider the exis= tence of a zone,
> >=C2=A0 =C2=A0the act of zone transfer between two entities, nor th= e identities of
> >=C2=A0 =C2=A0the nameservers hosting a zone
> >
> > To further document the assumptions, consider adding that this th= reat
> > model doesn=E2=80=99t consider/protect the mechanisms to decide o= n triggering
> > the zone transfer (e.g., protecting NOTIFY messages from an activ= e
> > attacker)
>
> Thats a reasonable point - I=E2=80=99ll add it. FYI - some operators d= o protect the NOTIFY
> with a TSIG for _some_ added protection.
>
> >
> > Section 6.2.=C2=A0 Per =E2=80=9CHowever it is noted that most wid= ely used open
> > source authoritative nameserver implementations (including both [= BIND]
> > and [NSD]) do IXFR using TCP by default in their latest releases= =E2=80=9D, as
> > this document ages, =E2=80=9Clatest release=E2=80=9D may not be m= eaningful.=C2=A0 Consider
> > providing a version number for [BIND] and [NSD].
>
> Yes - that makes sense here.

Thanks.

> >
> > Section 8.4 and 10.4.=C2=A0 As already mentioned by Martin and Jo= hn -- It
> > seems like a strong statement to say that IP ACLs are in the same=
> > class of =E2=80=9Cchannel authentication=E2=80=9D as mTLS.
>
> Hopefully addressed in the thread with Ben.

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

> >
> > Section 8.8.1.=C2=A0 It=E2=80=99s difficult to assess how effecti= ve this notional
> > padding approach would be for providing traffic analysis protecti= on.
> > 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 draf= t on the
> specific padding policy would address that in more detail.
>
> >
> > -- Is keeping state required to ensure that padding provides the<= br> > > 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 - inpu= t for the
> follow up padding policy draft - thanks!).

Exactly. Changes in sizes would be a prime traffic analysis metric.=C2=A0 T= his obfuscation would have to be consistently maintained to provide protect= ion (to the degree that this obfuscation is robust) against a persistent ob= server 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 b= etween balancing what's out of scope for a future, detailed specificati= on; and adding design considerations or cautions in a notional architecture= specified here.=C2=A0 I leave it to you and the rest of author team to ass= ess the right balance as these were just (optional) ballot comments.

Regards,
Roman

> Thanks and regards
>
> Sara.

--00000000000010f19b05c1a8b2a3--