[dhcwg] Stephen Farrell's Discuss on draft-ietf-dhc-dhcpv6-active-leasequery-03: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-dhc-dhcpv6-active-leasequery-03: Discuss

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 IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


This might seem like a lot of discuss points, but it's really
two main ones (privacy and use of TLS) broken out into what I
think are separable questions that might help us get the
discussion done quicker.

(1) I'm not sure I'm following the use-cases for this but
clearly this protocol could be used as part of a pervasive
monitoring toolkit, to track users or client-devices with very
fine granularity.  So a) can you explain the main valid
use-case(s) and b) did you consider RFC7258 in developing this
protocol?  The answers here might well result in a few changes
to my other discuss points below. I also had a quick peek at
5460, but note that pre-dates 7258 by quite a bit and I'm also
not clear how or if this protocol has the same goal of restoring
routes.  Note also that I am not claiming that there are no good
uses for this protocol, I'm just asking what (some of) those are
and how you considered the PM issue.  

(2) I also think you need to add (or reference) privacy
considerations text here - the information accessible via this
could have significant privacy impact. 

(3) Along the lines of (1) - can you say why all of the various
bits of data one could return are needed by the requestor here?
If not, then isn't there a good data-minimisation case to be
made for profiling down the information returned to the
requestor?  I think one can validly argue that the answers we
arrived at in 2009 (for 5460) might not be those on which we'd
reach consensus today, but this draft seems to (quite
understandably) assume that 2009's answers are still good
enough.  Did the WG consider that? 

(4) Having TLS is good. But I don't get why you've not reversed
the TLS client/server roles to make the requester the TLS
server, since it seems to me that authenticating and authorizing
the requestor here is the main thing and not authenticating the
DHCP server. So why not reverse the TLS roles? (I'll clear this
quickly but wanted to check in case it'd not occurred to folks.) 

(5) The TLS mutual authentication requirement is underspecified.
The sentence in 9.1 isn't really enough I think, you need to say
that all TLS sessions MUST be mutually authenticated and then
that has administrative consequences that might need more text.
For example, the DHCP servers need to trust the set of CAs that
requestors use - is it ok to be just silent on that?  I also
wonder about naming and other things - does there need to be
some profile of how the DHCP server is named vs. a TLS
certificate? 

(6) Why not just make the use of TLS mandatory or RECOMMENDED
here anyway - would that really hurt?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- I had a look at the DHCPv4 equivalent - is the plan that those
be as close to one another as possible? If so, then the
"DHCPTLS" vs. "STARTTLS" thing seems odd, as does the
duplication of text in the two - would it not have been better
to develop a separate spec for how to talk to a DHCP v4 or v6
server using TLS? I think that'd be cleaner for all sorts of
reasons, e.g. naming, the roles of the peers, TLS extensions
needed etc.

- sections 8/9: Sending the DHCP REPLY with no status code as a
way to indicate acceptance of TLS seems very hacky. Why is that
a good plan? I don't think STARTTLS works that way in other
protocols for example.

- somewhere: I think it'd be a fine thing if you referred to
RFC7525/BCP195 and said implementations need to follow that in
how they use TLS.

- section 10: why is (the usually mythical:-) 3315 a MUST NOT
here? I don't get that. I could see it being an EDONTCAR but I
don't see the harm if one did go mad and try use 3315. And I
could maybe, possibly, with a lot of a nose-holding, see a
universe in which one might use TLS server auth for the DHCP
server and 3315 to authenticate the requestor, so it seems odd
to rule that out in this way.