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

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2016 13:13:18 +1300

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.

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

Secondly, this seems underspecified. Something more like
https://tools.ietf.org/html/rfc7217#section-5 seems necessary.

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

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

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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 Feb 2016 01:46:29 +0000

On Friday, February 5, 2016 4:13 PM, Brian E Carpenter wrote:
> 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?

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

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

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

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

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

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

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 6 Feb 2016 15:10:51 +1300

Bonjour Christian,

> 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 opposi…

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

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

> 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 cou…

Yes, I think so - a hint that this is not exactly a new problem.

> 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 b…

Sigh. Again, RFC4086.

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

> 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

---

From: Christian Huitema <[email-masked]>
Date: Sat, 6 Feb 2016 05:42:49 +0000

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

> > 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?
> 
> > We could discuss whether OS API like "cryptgenrandom" or "/dev/random"
> are random or pseudorandom. I would rather not go there...
> 
> > 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.
> 
> > 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
> >>>
> > 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