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

[Sara Dickinson <[e-mail]>]

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

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

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

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

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

Thanks and regards

Sara.