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

[Stephen Farrell <[e-mail]>]

Hiya,

On 14/07/15 01:57, Kim Kinnear wrote:
> 
> Stephen,
> 
> In an attempt to narrow down the discussion, I've selected a few sections
> to respond to here, but I'm actually trying to respond to your entire 
> concern w.r.t. privacy.
> 
> On Jul 11, 2015, at 9:11 AM, Stephen Farrell <[e-mail]> wrote:
> 
>> 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.
> 
> I do not believe that we going to be able to give you the information
> as to which data elements are "necessary" and how they will be used.
> We simply don't know, and in many cases our customers won't (or even
> can't) tell us.  I think for the purposes of analysis here, that we
> should assume that people using Active Leasequery are going to use all
> of the data that the DHCP server has available to it about each client
> and that it can send out in an Active Leasequery response.  I don't
> doubt that vendor independent extensions will be used as well to
> enhance the information with specific items in different
> implementations.
> 
> Essentially, our customers are building a parallel database which
> contains essentially everything they can get from an Active Leasequery
> response (or a Bulk Leasequery response).  Trying to limit the data
> that they can acquire from an Active Leasequery by limiting it in this
> document will only, in my view, take us back to where they will find
> other approaches to acquire the missing information.  Which is exactly
> the reason that we developed an Active Leasequery-like capability in
> the first place -- to remove the need to develop one-off solutions for
> each customer.

Yes, there're deep conflicting principles here - we have the general,
long-standing and well understood computer science goal that we all
understand of enabling re-use as much as possible vs. the much more
recent and not at all well understood privacy goal of limiting
(ab)uses. (One elucidation of which is that re-use for purposes not
initially declared should be forbidden.) I doubt we'll solve that
general conundrum in this case, and we shouldn't try do that by
blocking a document like this.

However, while we won't solve the general problem here, I think it's
fair to push back a bit and ask what are the main things that users
of the shadow DB are after. It's a little hard to believe that it's
really all down to fixing up routes, but for all I know maybe it is.
I do know that it's really hard to do a realistic privacy analysis
without knowing anything about that - in such cases one generally
tends to conservatively assume the worst, as you can imagine. And
maybe that worst is not the reality, in which case we'd be wasting
our time and maybe producing a worse outcome by making such bad
and pessimistic assumptions.

> 
> That said, it would certainly serve the goal of privacy if there were
> no standardized way to acquire this information.  We have no
> particular incentive to standardize this Active Leasequery other than
> it seemed like a "good thing to do".  Clearly from a privacy standpoint
> it isn't.  Seems like from a user's standpoint, though, there is some
> value in having this standardized.  Thus, we have added TLS support at
> the request of the former AD.
> 
>>>
>>> 	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.
> 
> You have put this well -- what is the probability and downsides of
> making the information the DHCP server knows easily available vs the
> cost of make this spec more restrictive.
> 
> I want to emphasize as well that we expect that the people who control
> the information on the DHCP server are the same people who will
> control the configuration of the DHCP server (regarding Active
> Leasequery) as well as the database constructed by the requestor of
> the Active and Bulk Leasequery information.
> 
> Yes, someone could mistakenly leave their firewall unconfigured
> regarding DHCP and thus let anyone see what the DHCP server knows.
> 
> Of course this can already be done with DHCPv6 Bulk Leasequery (RFC
> 5460) as well as DHCPv6 Leasequery (RFC 5007).  I recognize, however,
> that just because some existing protocols don't protect some data is
> no justification for allowing a new protocol to not protect some data.
> So I'm not using that as a justification for anything, yet I did want
> to point it out.
> 
> I believe that anyone who allows TCP connections to port 67 on their
> DHCP server is at risk of losing data to Bulk Leasequery already, and
> so one would normally prevent TCP connections to port 67.  And that
> would also cover Active Leasequery.
> 
> But mistakes certainly do happen when configuring networks, and I deal
> with supporting customers who make such mistakes frequently.  So
> perhaps simply telling people to "prevent access by unauthorized
> requestors" isn't enough (which is essentially what we have done 
> so far).
> 
> It would be straightforward to alter the draft to say that you MUST
> NOT make Active Leasequery access available by default, and that it
> MUST require explicit configuration in order to allow the DHCP server
> to respond to any Active Leasequery request.  Then someone would have
> to take an action to create a privacy problem.
> 
> Further we could say that it MUST take explicit configuration to allow
> Active Leasequery without TLS even if TLS wasn't implemented.  So you
> would have two explicit hurdles to overcome to do something dumb
> regarding privacy.  This would largely prevent people who knew nothing
> about Active Leasequery from having it enabled it on their servers,
> as well as encouraging others to use it in a protected way.

Your suggestions from the above two paragraphs and your earlier idea
of being able to configure which information will be reported seem
to me like they're definitely on the right track. If the WG think
those are ok and if folks would implement like that then I think we
should probably be able to close out on all this fairly quickly.

That said, I'll admit that while using TLS is fairly simple, having
it on by default does have some admin overhead, so I'd like to be
confident that that overhead is something implementers would likely
find worth putting up with before we consider that to be the right
answer here. To be clear - the overhead is nothing to do with CPU
consumption of run-time TLS, it's all down to ensuring the keys and
certificates required are provisioned in a way that users find
acceptable. That can be done, but requires some more developer effort
compared to just opening a cleartext socket.

> 
>> 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.
> 
> Our answer is no, we don't believe that we should go further and
> require TLS, in that we don't see this protocol as creating a privacy
> exposure of sufficiently unusual magnitude to warrant taking that
> extra step.  Possibly because we don't view the information available
> as unusually ... useful to someone intent on violating privacy
> concerns.  Useful, certainly, but not extraordinarily useful, and so
> not requiring extraordinary measures to protect.

Well I'd argue that mandating use of TLS is getting more and more
common and will soon be far from extraordinary for anything with
potentially bad privacy consequences. Think the US OPM or Target
or Sony or even hacking-team - if systems defaulted to protecting
data at rest and in transit as much as possible, then it could well
be the case that fewer such incidents will happen.

Cheers,
S.

> 
> Thanks -- Kim
>