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

[Allison Mankin <[e-mail]>]

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 <[e-mail]> wrote:

> Hi Sara!
>
> > -----Original Message-----
> > From: iesg <[e-mail]> On Behalf Of Sara Dickinson
> > Sent: Thursday, May 6, 2021 6:13 AM
> > To: Roman Danyliw <[e-mail]>
> > Cc: [e-mail]; [e-mail]; The IESG <[e-mail]>;
> draft-
> > [e-mail]; [e-mail]
> > 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 <
> [e-mail]>
> > 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.
>
>