Re: [Gen-art] Gen-ART Last Call review of draft-ietf-dhc-anonymity-profile-06

[Christian Huitema <[e-mail]>]

On Friday, February 5, 2016 6:11 PM, Brian Carpenter wrote
> Bonjour Christian,

Hello Brian

Thanks for the suggestions. I will update the draft accordingly, but I will also wait a few day to check whether there is more feedback coming from other reviewers.

-- Christian Huitema




> 
> On 06/02/2016 14:46, Christian Huitema wrote:
> > On Friday, February 5, 2016 4:13 PM, Brian E Carpenter wrote:
> >> ...
> >>
> >> Document: draft-ietf-dhc-anonymity-profile-06.txt
> >> Reviewer: Brian Carpenter
> >> Review Date: 2016-02
> >> IETF LC End Date: 2016-02-15
> >> IESG Telechat date:
> >>
> >> Summary: Almost ready
> >> --------
> >>
> >> Comment:
> >> --------
> >>
> >> There is a reciprocal-RAND IPR disclosure against this draft
> >>
> >> Minor Issues:
> >> -------------
> >>
> >>> 3.5.  Client Identifier Option
> >> ...
> >>>   In contradiction to [RFC4361], when using the anonymity profile, DHCP
> >>>   clients MUST use client identifiers based solely on the link layer
> >>>   address that will be used in the underlying connection.
> >>
> >> The use of "solely" bothers me. I understand why the ID must be based on
> >> the MAC address, but why can't it be (for example) a hash of that address
> >> with a pseudo-random nonce? "Solely" seems to exclude that sort of
> >> solution.
> >
> > The intent is not to exclude solutions that hash the MAC with something
> else, but rather to ensure that the station does not disclose more information
> than already contained in the MAC -- by opposition to using long term
> identifiers, as specified in RFC 4361. What wording would you suggest?
> 
> Good, we agree on the intent at least. Would you agree to something like
> "MUST use client identifiers based solely on the link layer
> address that will be used in the underlying connection, which
> MAY be obfuscated by a technique such as a hash."
> 
> 
> >
> >> ...
> >>>   There are usages of DHCP where the underlying connection is a point
> >>>   to point link, in which case there is no link layer address available
> >>>   to construct a non-revealing identifier.  If anonymity is desired in
> >>>   such networks, the client SHOULD pick a random identifier that is
> >>>   unique to the current link, using for example a combination of a
> >>>   local secret and an identifier of the connection.
> >>
> >> Firstly, s/random/pseudo-random/ and s/unique/highly likely to be
> unique/
> >
> > How "pick a randomized identifier that is highly likely to be unique to the
> current link?"
> >
> > We could discuss whether OS API like "cryptgenrandom" or "/dev/random"
> are random or pseudorandom. I would rather not go there...
> 
> OK. That, or cite RFC4086.
> 
> (I had a similar problem for draft-ietf-anima-grasp and ended up thus:
> 
>    The Session ID SHOULD have a very low collision rate locally.  It
>    MUST be generated by a pseudo-random algorithm using a locally
>    generated seed which is unlikely to be used by any other device in
>    the same network [RFC4086].
> )
> 
> 
> >
> >> Secondly, this seems underspecified. Something more like
> >>
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ie
> >> tf.org%2fhtml%2frfc7217%23section-
> >>
> 5&data=01%7c01%7chuitema%40microsoft.com%7c8d5e624df9d64ef14b4e0
> >>
> 8d32e8a4e80%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GsVV%2b
> >> tNt8FeXjyqO%2f6HM%2f8u2fR3EOG4RmHTeP9TJbi4%3d seems necessary.
> >
> > What you see above is the garbage inflicted by our server based anti-
> phishing protection. But I digress.
> >
> > I am a bit reluctant to be too prescriptive on the algorithm, because we
> have little implementation experience so far. The general patter of hashing a
> secret and an identifier is well known. We could certainly throw in an
> informational reference to RFC 7217 if you believe that this helps.
> 
> Yes, I think so - a hint that this is not exactly a new problem.
> 
> >
> >
> >>> 4.3.  Client Identifier DHCPv6 Option
> >> ...
> >>>   When using the anonymity profile without the benefit of randomized
> >>>   link-layer addresses, clients that want to protect their privacy
> >>>   SHOULD generate a new randomized DUID-LLT every time they attach to
> a
> >>>   new link or detect a possible link change event.
> >>
> >> Firstly, again, it's always pseudo-random in a computer.
> >>
> >> Secondly, it isn't obvious from the text that you are really abusing the RFC
> >> 3315 format by using a bogus MAC address and bogus timestamp. I
> suggest
> >> rewriting the sentence:
> >>
> >>    When using the anonymity profile without the benefit of pseudo-random
> >>    link-layer addresses, clients that want to protect their privacy
> >>    SHOULD generate a new pseudo-random identifier in DUID-LLT format
> >>    every time they attach to a new link or detect a possible link
> >>    change event. Syntactically this identifier will conform to [RFC3315]
> >>    but its content is meaningless.
> >
> > Agree with the addition of the "meaningless" comment.
> >
> > I would keep "randomized" instead of pseudo-random, because if we do
> write pseudo random, someone is bound to understand "do not use the
> cryptographic API that guarantees a high degree of entropy but use a
> Mersenne Twister instead."
> 
> Sigh. Again, RFC4086.
> 
> >>> 4.5.2.  Prefix delegation
> >>>
> >>>   The interaction between prefix delegation and anonymity require
> >>>   further study.  For now, the simple solution is to avoid using prefix
> >>>   delegation when striving for anonymity.  When using the anonymity
> >>>   profiles, clients SHOULD NOT use IA_PD, the prefix delegation form of
> >>>   address assignment.
> >>
> >> I see the issue, but this may be problematic for some scenarios. I think this
> >> choice needs to be reviewed in 6man. I will make that happen.
> >
> > What about inserting there a text explaining that "further work on the topic
> is needed," or some such?
> 
> Sure. My concern is that you might unintentionally block off a useful
> path with that SHOULD NOT. At least there should be a configuration option
> to allow IA_PD.
> 
> >>> 5.  Operational Considerations
> >>>
> >>>   The anonymity profile has the effect of hiding the client identity
> >>>   from the DHCP server.  This is not always desirable.  Some DHCP
> >>>   servers provide facilities like publishing names and addresses in the
> >>>   DNS, or ensuring that returning clients get reassigned the same
> >>>   address.
> >>
> >> Many DHCP servers will only give addresses to pre-registered MAC
> >> addresses.
> >> That should probably be noted, because it will prevent all use of pseudo-
> >> random MAC addresses. (Another reason to hash the MAC address with a
> >> nonce.)
> >
> > Yes, we can add a caveat. But the real rule is that some networks will block
> randomization, and for those network clients have to either refuse to connect
> or not use this spec...
> 
> Agreed.
> 
>    Brian