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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 04 May 2021 14:44:03 -0700

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

Section 1.  s/can make reconnaissance trivial/can make reconnaissance and
attack targeting easier/

Section 1.  Per “… zone walking is now possible with NSEC3 due to
crypto-breaking advances”, a reference here would be helpful.

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/

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.

Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.

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)

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

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.

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?

-- Is keeping state required to ensure that padding provides the appropriate
obfuscation over time?

---

From: Sara Dickinson <[email-masked]>
Date: Thu, 6 May 2021 11:13:11 +0100

> On 4 May 2021, at 22:44, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> ———————————————————————————————————

Hi Roman, 

Many thanks for the review. 

> Section 1.  s/can make reconnaissance trivial/can make reconnaissance and

Yes. 

> crypto-breaking advances”, a reference here would be helpful.

Agreed and requested by another reviewer - let me dig a good one out. 

> has prompted further work on an alternative mechanism/This promoted work on an

That seems reasonable. 

> 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)?

> Section 1.  Editorial.  “… must cater for accepting …” doesn’t parse for me.

“must therefore accept”?

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

> “latest release” may not be meaningful.  Consider providing a version number

Yes - that makes sense here.

> a strong statement to say that IP ACLs are in the same class of “channel

Hopefully addressed in the thread with Ben.

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

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

Thanks and regards

Sara.

---

From: Roman Danyliw <[email-masked]>
Date: Thu, 6 May 2021 12:23:32 +0000

Hi Sara!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Sara Dickinson
> Sent: Thursday, May 6, 2021 6:13 AM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; [email-masked]; The IESG <[email-masked]>; draft-
> [email-masked]; [email-masked]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-dprive-xfr-over-tls-11:
> (with COMMENT)
> 
> 
> 
> > 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
> > Section 1.  s/can make reconnaissance trivial/can make reconnaissance
> > and attack targeting easier/
> 
> Yes.
> 
> >
> > 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.

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

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

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

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

---

From: Allison Mankin <[email-masked]>
Date: Thu, 6 May 2021 08:45:58 -0400

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 <[email-masked]> wrote:

> > > On 4 May 2021, at 22:44, Roman Danyliw via Datatracker <
> [email-masked]>
> > wrote:
> > >
> > Thats a reasonable point - I’ll add it. FYI - some operators do protect
> the NOTIFY
> > with a TSIG for _some_ added protection.
> >
> > >
> No problem.  I know a number of us made a related or identical comment.
> I'll follow along in the DISCUSS made by Ben.
>
> > >
> 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.
>
>