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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
