Re: [Hipsec] RFC5201-bis: Stephen Farrell's DISCUSS questions

[Tom Henderson <[e-mail]>]

Some more comments inline below:

On 07/21/2014 10:19 AM, Rene Hummen wrote:
> Please, find my comments inline.
>
> On 18 Jul 2014, at 08:57, Tom Henderson <[e-mail]> wrote:
>> I'm reposting several questions and comments from Stephen Farrell
>> regarding RFC5201-bis, so that we can have some list discussion.
>> See below (quoted verbatim from:
>> https://datatracker.ietf.org/doc/draft-ietf-hip-rfc5201-bis/ballot/)
>>
>>
>>
 >> The main issues below for discussion seem to be:
>>
>> - what safeguards exist to reduce tracking of users? - questions
>> about the choices of certain algorithms and modes and whether they
>> are still current
>>
>> I'll open some more issues in the tracker if we don't get to
>> consensus quickly.
>>
>> ----------------------------------------------------------------
>>
>>
>> This review is based on the diff from 5201 [1]
>>
>> [1]
>>
>> https://tools.ietf.org/rfcdiff?url1=rfc5201&url2=draft-ietf-hip-rfc5201-bis-14.txt
>>
>>
>>
Work started on this in 2009 it appears and the backwards
>> incompatible changes made to the BEX are roughly what I'd expect to
>> have seen for good work done around that time. However, some things
>> have changed since, that I don't see reflected in the changes made
>> to the BEX, so I'd like to chat about those for a bit, in case
>> they're still malleable. If it is really the case that the boat
>> has sailed for such changes, then that's life, but I wonder has it?
>> (I really don't know for HIP.)
>>
>> I think the features in the changes to the BEX that one would
>> consider noteworthy were that work done today are:
>>
>> (1) Mandating some form of variability of, and confidentiality for,
>> the (non-routable?) HIT to enhance privacy or at least mitigate
>> trival passive tracking of activity across time and different
>> connections. (Or maybe the "anonymous HI" mechanism achieves this,
>> I wasn't sure? If it does, then why have any other?)
>
> In my opinion, stable HITs are actually a desirable property for HIP.
> As a fixed-length and _verifiable_ representation of the HI, they can
> be used for access control purposes at end hosts as well as at
> middleboxes (as part of HIP’s middlebox friendliness). Moreover, HITs
> are used as stable identifiers in the HIP Certificate extension [1].
> In the end, user privacy with stable HITs/HIs appears to be as good
> or bad as it currently is with mutual certificate-based
> authentication, e.g., in case of TLS.
>
> As mentioned above, short-lived (anonymous) HIs can be used to
> prevent tracking of users across HIP sessions. Then, however, user
> authentication requires, e.g., application layer passwords much like
> current user->service authentication of TLS-protected data
> transmissions on the web.


I agree with Rene's comments above, except I might say that anonymous 
HIs should in theory provide no worse tracking exposure than current 
approaches that use semi-stable IP addresses, versus "preventing 
tracking of users" (HIP doesn't block tracking by other means).

The question I have is whether a "tracking considerations" paragraph 
ought to be added to the security considerations section, along the 
lines of:
- repeated use of stable HITs will likely increase tracking exposure, 
for better or worse (caveat emptor)
- use of anonymous HITs might eliminate additional tracking exposure, at 
the cost of requiring authentication mechanisms at higher layers

>
> So, from my point of view, there is a case for stable as well as for
> anonymous (i.e., variable) HITs/HIs.
>
>> (2) There is no support for newer elliptic curves or
>> representations like 25519.
>
> HIPv2 incorporates mechanisms to update the protocol with newer
> curves. Is there really the need to revise the document now or should
> we rather wait until the need for newer curves arises due to demand
> by certain applications/implementors?
>
> As for the representation, HIPv2 appears to require “Octet-string
> format" [2]. Is there a need to add protocol agility regarding the
> encoding (i.e., a new ECC parameter field)?
>
>> (3) Continuing to support the 1536 MODP DHE group but not
>> supporting the 2048 equivalent seems a bit odd, as does not having
>> a code point for the 4096 but group. Similarly, making the 1536 bit
>> group the MTI (in 5.2.7) is odd as is the assertion that "web
>> surfing" can use a lower security level.
>
> I am not aware of the criteria that were used for choosing the DHE
> groups. Can someone else comment on this?

I don't recall offhand, other than that we went through a round of 
review with CFRG back in 2012 and we ended up modifying our crypto 
selections based on the feedback received.  Bob and Tobias have been the 
caretakers of the crypto selections in HIPv2 in general, so I defer to them.

>
>> (4) (5.2.8) Did the WG discuss deprecating the NULL encryption
>> option? (Haven't you finished testing yet:-)
>
> I think this has been addressed on the mailinglist.

Stephen, I wonder whether saag discussion has died down now and there 
are any comments on my proposed resolution posted here?

http://www.ietf.org/mail-archive/web/hipsec/current/msg03894.html

>
>> Also - there are no counter modes, is that wise?
>
> HIP DEX defines AES-128-CTR for HIP_CIPHER [3]. However, I just
> realized that it does not specify its use for the ENCRYPTED
> parameter. Instead, the specification focuses on the special-purpose
> ENCRYPTED_KEY parameter. So, some work would be needed to carry this
> over to HIPv2.
>
>> Finally, HIPv1's encryption codepoint 1 was for a 3DES option, but
>> here you have 1 == NULL, yet you deprecate codepoint 3, which is
>> confusing. Why is that?
>
> Is this maybe a specification hiccup?

I introduced this "DEPRECATED" as part of comment resolutions back in 
2012 (someone in CFRG suggested to drop it), in this post:

http://www.ietf.org/mail-archive/web/hipsec/current/msg03557.html

However, HIP_CIPHER is a new parameter, so nothing really needs to be 
deprecated.  Perhaps "RESERVED" would have been better (or remap 
AES-256-CBC to value 3).

Any concern if I change DEPRECTED to RESERVED and add the comment that 
it is unused, such as:?

   Reserved     3    (unused value)

Or would it be better to just omit the line and skip from 2 to 4?

>
>> (5) Requiring HMAC-SHA-1 in 6.4.1 seems a bit odd. If HMAC-SHA-256
>> is supported, then why not just use that? Is there are real benefit
>> in the sha1 variant?
>
> SHA-1 is only defined for use with ECDSA_LOW. Currently, the only
> defined curve for this profile is SECP160R1. Seeing that, e.g., CoAP,
> recommends secp256r1 [4] even for constrained devices, we could
> probably remove the ECDSA_LOW profile in HIPv2 altogether.
>
>> Comment (2014-06-26)
>>
>> - abstract: SIGMA-compliant is a bit of a mouthful for an abstract
>> - how many readers do we really expect to get that?
>
> I suggest to simply remove the “SIGMA-compliant” in the abstract.
> It’s mentioned again (with a reference) later on in the introduction
> [5].

+1

>
>> - 1.1: Saying the HI is the identity of the host seems a little
>> overstated to me, but I guess that's accepted as a description for
>> HIP, so not objecting, but it'd seem more natural to me to say that
>> a HI is an identifier that a host can use. (Presumably
>> load-balancing and mobility scenarios could mean that a private key
>> could be on more than one host or one "host" might have >1 private
>> key.)
>
> I think the current description of the HI is more intuitive if not
> entirely precise. It doesn’t cover the mentioned (corner-)cases, but
> I personally prefer it the way it is right now.

I'm not sure what text you are referring to.  Section 1.1 says that "The 
HI is a public key and directly represents the Identity of a host. " but 
it doesn't say that the HI "is" the identity.

>
>> - section 3: 3110 doesn't seem like a great reference for RSA.
>> Isn't there better?
>
> I am not sure what this is referring to.

I think this refers to the first reference to RSA as an algorithm in 
general (in Section 3).  Later references use RFC3110 to refer to the 
specific encoding defined there, and I think that we need to preserve 
those references.  So I think Stephen's comment is to replace this 
reference in Section 3:

  HIP implementations MUST support the Rivest Shamir Adelman (RSA)
    [RFC3110] public key algorithm

with something else.  Any ideas of what to put there?  RFC3110 itself 
cites Schneier's Applied Cryptography book when referring to RSA.

- Tom