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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 08 Jul 2015 04:42:06 -0700

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.

---

From: Kim Kinnear <[email-masked]>
Date: Thu, 9 Jul 2015 17:42:39 -0400

Stephen,

Thanks for your review.  My comments are inline, below...

> https://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv6-active-leasequery/

	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.

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

	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.

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

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

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

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

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

> 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

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

	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.
> a good plan? I don't think STARTTLS works that way in other

	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.  
> RFC7525/BCP195 and said implementations need to follow that in

	Great!  Will do.
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Jul 2015 23:57:29 +0000

> 	extensions to our DHCP server, since implementing this is a

To add my two cents there: I believe that the Security Section should be updated to point out the "information disclosure" risk. Information disclosure happens when unauthorized clients connect to the server and manage to extract sensitive information, such as leases, time of connection, or delegation of prefixes to specific customers. The main mitigation proposed in RFC 5460 is to reject connections from unauthorized customers, and that mitigation shall be explicitly mentioned in the security section. 

Here are the details of the reasoning:

1) Privacy analyses already assume that the DHCP server knows the relation between MAC Address and IP address, and that network management systems can obtain this information from the DHCP server.

2) Privacy analyses also assume that any "on-link" party can find the relation between MAC Address and IP Address, using ARP or network discovery.

3) Privacy analyses assume that the mapping of prefix delegation to ISP customer identity is only known by the ISP, and is only disclosed on a case by case basis using some formal channels.

The proposed extensions allow for real time monitoring of DHCP leases, including in particular prefix delegations. This clearly changes some of our privacy assumptions. With this protocol, the lease information can be accessed in real time by any party that manages to establish a connection to the DHCP server -- not just parties on the same link as the target, and not just devices managed directly by the ISP.

The draft does specify some access control mechanism to protect the information. Namely, section 9.1. Accepting connection states that:

   DHCPv6 servers that implement DHCPv6 Active Leasequery listen for
   incoming TCP connections.  Approach used in accepting the requestor
   connection is same as specified in DHCPv6 Bulk Leasequery [RFC5460].

The corresponding text in section 7.1. of RFC 5460 states that:

   Servers MAY restrict Bulk Leasequery connections and LEASEQUERY
   messages to certain clients.  Connections that are not from permitted
   clients SHOULD BE closed immediately, to avoid server connection
   resource exhaustion.  Servers MAY restrict some clients to certain
   query types.  Servers MAY reply to queries that are not permitted
   with the NotAllowed status code [RFC5007], and/or close the
   connection.

That's pretty weak, because there is no good detail here of how the "certain clients" are identified. The STARTTLS option does not appear to infer Client Authentication. I assume that when the access control is implemented, it is done via IP address, but that seems weak.

-- Christian Huitema

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 10 Jul 2015 10:48:20 -0400

Stephen,

This language was in the first draft submission of this protocol,
so it wasn't something added along the way.  I would say that
the arguments for this language are:

  1. If you want authentication, use TLS which is a documented part of
  this protocol.

  2. The RFC 3315 authentication explicitly does not deal with data
  security, and so again, TLS gives you that.

  3. RFC 3315 authentication has not been specified over a TCP
  connection to the DHCP server.  Are there things you would need to
  think about here?  I can't think of any right off, but it still
  makes a nice argument.

  4. Why allow *two* security/authentication mechanisms for one
  protocol.  Yes, we could imagine someone using it, but if some
  people use it and some people use TLS, then where does that leave
  us?  Not communicating securely, seems to me. 

Bottom line:  Just because we can imagine someone doing this doesn't
make it a good thing to do.  So, I would say:  If you want
authentication or security, use TLS.  If not, not.  I see zero value
in allowing an intermediate solution which just makes the likelihood
of actually communicating significantly less.

I think this statement -- MUST NOT use 3315 authentication -- should
stand.

Regards -- Kim

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Jul 2015 15:54:27 +0100

Thanks Kim,

I'm fine with that being there, but was just wondering if there
was a specific reason and didn't intend to suggest a change.

Cheers,
S.

PS: Will respond to your other mail later today

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 11 Jul 2015 14:11:38 +0100

Hi Kim,

Sorry for the slowish response.

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

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

> 	misunderstood some of how that works, and I'll discuss that

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

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

> 	considered a threat to privacy in the same way the DHCP

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.

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

> 	they really need.  Would that be sufficient to deal with

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?

> 	Have we missed something here?

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

> 	to drafts that document this kind of thing, we'd love

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

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

---

From: Ted Lemon <[email-masked]>
Date: Sun, 12 Jul 2015 13:50:10 -0500

> of the purpose(s) to which this data will be put.
The main purpose of the protocol is to install routes and/or layer 2 
information into provider edge routers by the provider as a result of 
successful DHCP configuration that has happened.   This is a requirement 
for IPv6 to work in an ISP deployment.   Of course you could use this 
for almost anything, but that is the real intended application: what 
people are doing with it right now.

You could use it to populate an IP Address Management database as well; 
I don't know if anybody is doing this, but it would certainly work.   
The point is that the purpose of this is to make it possible for the 
network operator to do the various sorts of bookkeeping that are needed 
to make the network work.

The devices being monitored using this technology are generally going to 
be customer routers, not individual hosts.   The communications can 
generally be assumed to be travelling across provider networks: the 
usefulness of the data is localized, and we would not expect to see it 
being transferred between provider data centers (typically) or across 
backbone links not operated by the provider (typically).

I think for the sake of robustness in the face of active attacks it 
would be worth requiring TLS, since it's a lot easier to snoop data off 
of a single stream or off of the DHCP server than it is to capture it by 
sniffing DHCP transactions on the wire; indeed, one of the main points 
of this specification and the other leasequery specifications is that 
snooping on DHCP traffic, even for the router through which the traffic 
is passing, is failure-prone in a variety of ways.

I think the motivation for not requiring TLS is just that it's more 
work, one more thing to configure, and probably won't usefully conceal 
information from anybody with the wherewithal to snoop on the provider's 
network anyway.   I suggested this to Kim when I did my review during 
the working group last call, but he felt that a less extreme fix than 
the one I recommended would be adequate: simply allowing the server to 
require TLS.

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 13 Jul 2015 20:57:30 -0400

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.

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

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.

> balance quite right, but then as I said I don't yet understand the

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.

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

Thanks -- Kim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 02:30:41 +0100

Hiya,

> the first place -- to remove the need to develop one-off solutions for

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.

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

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

---

From: Kim Kinnear <[email-masked]>
Date: Tue, 14 Jul 2015 13:30:00 -0400

Stephen,

Maybe we are getting closer to something we can both
live with, here...

> really all down to fixing up routes, but for all I know maybe it is.

It is certainly well beyond fixing up routes.  That is one use of Bulk
Leasequery, but Active Leasequery is designed to give administrative
personnel and their tools access to the IP <-> DUID mapping.
Additionally, the information sent in about the type of device (often
found in the vendor-class option) and any
vendor-specific-information-option is used as is the
relay-agent-remote-id in the Relay-Forward message.  The interface-id
would be another option that would be used.  Of course, the
client-fqdn option would be another oft-used item.

While certainly not the only use to which this data is being put, one
example use is to allow a service technician who is at someone's house
to access a tool back in the back office that will tell the technician
whether or not the device that they have in their hands has acquired
an IP address and how far (if at all) that it has progressed through
the provisioning process unique to this service provider.  Certainly
the DHCPv6 Active Leasequery information isn't the only information
that is used when troubleshooting a problem like this, but some of
that information would be useful to the diagnostic tool that the
service technician would access.

There are many other back-end OSS kinds of things that people can do
with this data, including billing for service where connectivity is
defined as "service".

> and pessimistic assumptions.

I clearly don't understand what a "realistic privacy analysis"
involves, since I think that what authorized people can do with the
information that they can get by Active Leasequery or regular RFC 5007
Leasequery or RFC 5640 Bulk Leasequery is all pretty reasonable stuff.
How this data is used by the legitimate users seems to me to be a
non-issue, since anyone with access to the DHCP server can certainly
get it to export this information with little effort. Ensuring that it
is only used by legitimate users seems the goal.

As I said, we are more than willing to say that you SHOULD allow
configuration of which options you will allow to be sent through an
Active Leasequery connection.  We could even make that a MUST if it
would ease some of your concerns.

> should probably be able to close out on all this fairly quickly.

That would be great, and I think the WG would have no problem with
making that a SHOULD or a MUST.  I can't control what people
implement, but I think that sort of requirement typically isn't a
difficult thing to implement in a server's configuration, so there
would probably be good compliance with that recommendation (SHOULD) or
requirement (MUST).

> compared to just opening a cleartext socket.

I see no problem in making TLS the default whether or not it is implemented,
and requiring explicit action to *not* use TLS even if it is not available
in a particular implementation.  While a bit unusual, nobody is going to
have a problem with that -- especially if the alternative is to not have
this standardized at all.  

> be the case that fewer such incidents will happen.

Whether or not TLS becomes mandatory soon is something that will be
interesting to observe.  I don't think that the data we are talking
about the DHCP server making available to legitimate requestors with
Active Leasequery has particularly bad privacy consequences.  I think
the DHCP data is at the other end of that spectrum.  The Target or Sony
data and the DHCP data we are discussing here are so far apart from a
privacy standpoint that I'm astonished that we are even having to
discuss comparing them here.

I recognize that you want to move the world forward to be more secure
from a privacy standpoint.  We have agreed to change the document to
make accidental exposure of the DHCP data much less likely and I'm
glad we have done so.  

In your quest to move the world forward to a more secure future, I
would respectfully suggest that there must be protocols whose data,
were it exposed, would be more egregious than the relatively benign
data we are discussing here.  Perhaps you might move forward to make
TLS implementation and use mandatory in one of these other protocols
where the result would have more obviously concrete benefits?

Thanks -- Kim

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jul 2015 20:56:00 +0100

Hiya,

> Maybe we are getting closer to something we can both

Yes. I'd say time to start crafting text if you don't get push
back from the WG on the ideas below.

Thanks for explaining some of the debugging/diagnosis stuff. I'd
argue that that should allow for a security/privacy consideration
to be added here recommending that data acquired via this protocol
be deleted when no longer needed, which for debugging purposes
is pretty promptly I'd imagine. Hanging on to stuff like that
when you don't need it is just a liability. Or you could say
that alongside the bit where you discuss being able to
configure which data to allow be sent. (Note though that this
is offered as a comment and not as a blocking discuss thing.)

Cheers,
S.

PS: I'd note that reports indicate that the Target breach
started with a fridge vendor's maintenance system. [1] Just
because some subsystem or data seems unimportant doesn't
mean it's not a fine way in for later fun and profit.

[1]
http://www.theregister.co.uk/2014/02/08/fridge_vendor_pegged_as_likely_source_for_target_breach/