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

[Stephen Farrell <[e-mail]>]

Hi all,

Apologies for the slow response.

On 21/07/14 23:50, Tom Henderson wrote:
> 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.

Actually TLS 1.3 is aiming to address this, so that the cert used
for client-auth is no longer sent in clear. IPsec also hides such.

However, I won't press this if you don't wanna go there now - it'd
be a large enough change and would probably take time.

I'll clear this one and if the WG want they can decide to pursue
that goal.

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

Fair enough. Will clear this too. I'd hope its fine to address
this when you're ready to, but wanted to check since some new
curves are likely to be added to other protocols soon.

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

Ok, so let's wait to hear from Bob/Tobias on this one.

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

Right, we're sorted there now I think.

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

Ok, I'll leave you to figure that out.

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

Your call, just seemed funny to me.

Let's consider this one mostly closed.

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

Since HMAC-SHA1 is as far as we know still secure, I'll make this
a comment. But removing the profile might be a good idea.

In summary, I'll clear except for point (3) until we see what
Bob/Tobias say. If the WG do want to continue discussion any
of the cleared points, I'm happy to help out there if that's
useful, but I'm no longer blocking on those.

Cheers,
S.


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