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

[Stephen Farrell <[e-mail]>]

Hi Kim,

Sorry for the slowish response.

On 09/07/15 22:42, Kim Kinnear wrote:
> 
> Stephen,
> 
> Thanks for your review.  My comments are inline, below...
> 
> On Jul 8, 2015, at 7:42 AM, Stephen Farrell <[e-mail]> wrote:
> 
>> 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.
> 
> 	The use cases for this protocol extension are centered around
> 	processing elements inside of a service provider that need to
> 	know the information that the DHCP server knows, in near real
> 	time.
> 
> 	Service providers often need to know the client-id/MAC to IP
> 	binding information as part of their online provisioning
> 	capability and their client troubleshooting capabilities.
> 
> 	They have historically been scraping log files to glean this
> 	information, or creating extensions to our servers to
> 	broadcast this information to the elements in their
> 	provisioning ensemble that need to know this information.  We
> 	have actually implemented a capability similar to what is
> 	documented in this draft and it is in use by a number of large
> 	service providers -- and we implemented it in no small part
> 	because we got tired of trying to help people debug their
> 	extensions to our DHCP server, since implementing this is a
> 	hard problem.
> 
> 	That is to say, this is not a speculative protocol.  Something
> 	that solves the same problem in a similar way is in wide use.

Sure, I don't doubt there's utility here. But the actual utility
is still vague for me. I also don't doubt that it's not vague for
you or those deploying but it's not really possible (for me) to try
analyse the privacy properties without some more detailed knowledge
of the purpose(s) to which this data will be put.

> 	We did not consider RFC 7258 as particularly relevant to this
> 	protocol since we expect that the requestors of this protocol
> 	will be processing elements that sit next to the DHCP server
> 	and would have direct access to the DHCP server's database (if
> 	the DHCP server allowed direct access to its database).

Right, but "sit next to" isn't quite an accurate way to describe
"can connect via TCP" which is what the protocol specifies. So I
guess we should be able to easily agree that a bit more work is
needed to consider 7258-related issues.

> 
> 	This protocol allows some separation and standardization of
> 	how to get the information out of a DHCP server in order to
> 	build a database that is substantially the same as that in the
> 	DHCP server.  We expect that the processing elements that are
> 	building that database are controlled by the same people that
> 	control the DHCP server, and that the same protections and
> 	controls that are placed access to the DHCP server's data are
> 	also placed on the data garnered by the requestor of an active
> 	leasequery.
> 
> 	We intended the use of TLS and the process of verifying the
> 	TLS certificates to be the mechanism that a server would use
> 	to ensure that the requestor of the active leasequery was
> 	allowed to access the data from the DHCP server.  We may have
> 	misunderstood some of how that works, and I'll discuss that
> 	later.

Right. Getting the TLS text right should be fairly easy.

> 
> 	Ultimately, we expect that the people in charge of the data on
> 	the DHCP server are the same people in charge of the data that
> 	a processing element can discover from the DHCP server through
> 	the use of the active leasequery protocol.  These same people
> 	have control of the data in both elements (as well as the
> 	network on which the raw DHCP data flows).  Of course all of
> 	this information can be garnered from a tcpdump of the wire on
> 	which the DHCP server sits (and we have customers doing that
> 	too, to meet their needs for a near-real time database of
> 	client<->IP address binding information).

Sure a local tcpdump is what it is, but if someone deploys this
without implementing and turning on TLS and screws up their f/w config
then the entire world could find this data. And with zmap that's no
longer unrealistic if the DHCP server has an IPv4 address. And we do
know that people do screw up f/w configs. So the thing to analyse I
think is the balance between the probability and downsides of
publishing this information to the world, vs. the costs of making
the spec more restrictive/protective. I'm not sure we've got that
balance quite right, but then as I said I don't yet understand the
beneficial uses of this.

> 
>>
>>
>> (2) I also think you need to add (or reference) privacy
>> considerations text here - the information accessible via this
>> could have significant privacy impact. 
> 
> 	Absolutely, we will do that.  I expect to say that the
> 	information obtainable from active leasequery is essentially
> 	everything that the DHCP server knows, and should be
> 	considered a threat to privacy in the same way the DHCP
> 	server's data is.

Cool. I'd say it may be better to chat some more before crafting
that text, but once we have the right level of analysis done the
text will be easy enough.

>>
> 
>>
>> (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?
> 
> 	Not really, as the service providers have a variety of use
> 	cases for this information inside of their ensemble of
> 	provisioning and support systems.

Right. I can well imagine that. I'm not sure if or how spreading
this kind of management data would match up with e.g. .eu data
controller requirements which speak to only using data for purposes
for which it was originally gathered but that might be an issue,
not sure. And that's a broader question anyway, so wouldn't be
fair to hold this up on that basis I reckon, but maybe someone
already knows.

> 
>> 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? 
> 
> 	I could see adding some words to the draft that would
> 	say that the server SHOULD provide some way to configure
> 	which DHCP options will be allowed to be sent over an
> 	active leasequery channel, to allow the minimization of
> 	information to take place by the people who know what
> 	they really need.  Would that be sufficient to deal with
> 	your concern here?

Interesting idea, and maybe a good way to go. Would it get
used do you think? Or would it require a bit more work to
define some groups of options that'd make sense to turn on
or off? And what'd be the right defaults to choose?

>>
>> (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.) 
> 
> 	We think that if you are using TLS, that the requestor
> 	has as much reason to ensure they are talking to right server
> 	as the server has to ensure that it is talking to a valid
> 	requestor.
> 
> 	So, no, it hadn't occurred to us to switch roles.  We have
> 	been assuming that if the server verifies the certificates of
> 	the requestor and the requestor verifies the certificates of
> 	the server, that each would be able to ensure that it was
> 	talking to someone that it trusted to be the right ...
> 	someone.
> 
> 	Have we missed something here?

No that's fine. I'll make that bit as cleared.

> 
>> (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.
> 
> 	Ok, we know from Scott Bradner's review that we managed to
> 	leave out the words that said that we expected the
> 	verification of the certificates in both directions to be the
> 	mechanism that the requestor and server would both use to
> 	ensure that they were talking to the right partner.
> 	We will be putting words in to that effect.  Phrased better
> 	that I did here, of course.
> 
>> For example, the DHCP servers need to trust the set of CAs that
>> requestors use - is it ok to be just silent on that?
> 
> 	We expected that the server will verify the CA's from the
> 	requestor.  I didn't think of that as trusting them, but
> 	perhaps I'm missing something here.
> 
>> 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? 
> 
> 	We were leaving the "given a certificate, how do you
> 	decide if this is someone you want to talk to" issue
> 	as something that was outside the scope of this draft.
> 	
> 	If you have any words that you would suggest or references
> 	to drafts that document this kind of thing, we'd love
> 	to hear them!

I think getting this right will be easy enough but maybe tedious
if we're waiting on me to write the text;-) But happy to try
help review text or find you someone who can do that. Or maybe
you could look at another recent spec that has similar mutual
auth TLS needs? (Perhaps SCIM has, not sure but I can look if
it helps.)


>>
>> (6) Why not just make the use of TLS mandatory or RECOMMENDED
>> here anyway - would that really hurt?
> 
> 	The draft says TLS SHOULD be implemented, which seems to
> 	be the same as RECOMMENDED.  We could say RECOMMENDED if
> 	you would rather we did so. 

SHOULD is the same as RECOMMENDED but isn't what I was trying to
ask.

I'm asking wouldn't it be better if the spec said that "Mutually
authenticated TLS MUST be supported and SHOULD be used and SHOULD
be the default."

Right now, it says TLS SHOULD be implemented, which is consistent
with overall IETF BCPs. I'm asking if, for this protocol, with
the potential privacy exposure, we ought go further that those (now
somewhat old) BCPs and say to just turn on TLS, since it ought not
be that hard and really ought be the default.

Cheers,
S.

PS: All the comment stuff below is fine, thanks.

>>
>>
>> ----------------------------------------------------------------------
>> 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.
> 
> 	Yes, they are essentially equivalent.  The message names
> 	are based on the precedents in each protocol.  We always
> 	try to make the message names fit in to DHCPv4 or DHCPv6,
> 	as opposed to making them fit in across two drafts.
> 
> 	We proposed one draft for both DHCPv4 and DHCPv6, and
> 	the WG, WG Chairs, and AD all *really* didn't like that,
> 	so we didn't do that.
>>
>> - 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.
> 
> 	I think so to, but that is the current precedent for the
> 	use of the status code in the DHCP protocols and it 
> 	is considered a bigger hack to break the precedent.  
>>
>> - 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.
> 
> 	Great!  Will do.
>>
>> - 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.
> 
> 	I'll do a little more research and get back to
> 	you on this one.  I don't want to hold up the
> 	discussions on the rest of these issues until
> 	I figure this one out.
> 
> 	Thanks -- Kim
> 
>>
>>
>> _______________________________________________
>> dhcwg mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dhcwg
>