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

[Brian E Carpenter <[e-mail]>]

Bonjour Christian,

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