IETF conflict review for draft-williams-exp-tcp-host-id-opt
conflict-review-williams-exp-tcp-host-id-opt-02

I think the previous conflict review response was correct, not the current one.

I think the way that this spec justifies the design decisions that may allow the HOST_ID option to be used for pervasive monitoring can be summarized as: the option merely puts back in host identification information that a middlebox otherwise would have stripped out. I don't think this is really satisfactory. RFC 7258 doesn't say that we will work to ensure that pervasive monitoring remains only as easy or hard as it was before the deployment of CGNs or application proxies. It says that we will work to mitigate pervasive monitoring. So from the perspective of mitigating PM, the loss of unique host identification on the egress side of address-sharing devices is a virtue.

Of course, the motivations for re-introducing host uniqueness are well-documented. But this draft doesn't link the specification of the option to those motivations in a way that provides the justification that RFC 7258 requires, IMO. In particular, the document allows for the HOST_ID to contain an IP address or subnet, optionally together with a TCP port number. Under some circumstances using the option in these ways leaks information that allows for correlating the activities of the host more broadly than if the option were not used -- e.g., if an application proxy uses the option in this way, then the host traffic on the egress side of the proxy can be newly correlated with the host's traffic that does not pass through the proxy. If instead the proxy used a random, locally unique ID in the option, this type of correlation would not be re-introduced. So why should the option support embedding an IP address and TCP port, if all it needs to provide is local uniqueness for the hosts sharing the public address? Doesn't an opaque locally unique ID suffice for the three use cases listed in the document?

I'd also like to discuss this one some more. So far, I've looked quickly
at the diff between the last one we reviewed and the latest version.
That's [1].

That diff absolutely does not convince me that the draft is now only
describing something already deployed. For example the latest one
still says "...intended to allow broad deployment of the mechanism 
on the public Internet." That remains entirely inconsistent with 
IETF BCPs and so I believe we should revert to the previous DNP
response to the ISE. 

If we reach consensus on that, then I'm not sure if we should try 
to identify all the "badness" in -07 or if we should just say "please
DNP, no material change from our POV." I think the latter is more
appropriate but maybe this is something we ought discuss with 
Nevil - what's the right/best kind of IESG response in such a 
situation. Which leads me on to...

Also - from the ballot it's not possible for an AD to determine
anything about why the ISE has returned this item. I think that
is also something about which it'd be good to chat with Nevil,
from a possible tooling POV but also from a transparency and
accountability perspective. I think when/if the ISE is interacting
with the IESG in cases like this, it would seem fairly obviously
beneficial if the ISE's perspective on what's changed was part 
of the record. (Or perhaps the ISE's editorial board, I don't even
know which applies.)

The history of this overall set of documents and their authors'
doggedness in attempting to achieve publication as an RFC
(which is an entirely reasonable thing for authors to do) would 
seem to indicate that we ought carefully consider if we're 
collectively (IETF+ISE+RFCed) sending a message that all one
has to do is keep asking and you can get any bad idea out as
an RFC. I think we do not want that perception to spread.
 
    [1] https://www.ietf.org/rfcdiff?url1=draft-williams-exp-tcp-host-id-opt-05&url2=draft-williams-exp-tcp-host-id-opt-07