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

From: Tom Henderson <[email-masked]>
Date: Thu, 17 Jul 2014 23:57:27 -0700

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

(2) There is no support for newer elliptic curves or
representations like 25519.

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

(4) (5.2.8) Did the WG discuss deprecating the NULL
encryption option? (Haven't you finished testing yet:-)
Also - there are no counter modes, is that wise? 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?

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

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?

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

- section 3: 3110 doesn't seem like a great reference
for RSA. Isn't there better?

---

From: Rene Hummen <[email-masked]>
Date: Mon, 21 Jul 2014 17:19:36 +0000

Please, find my comments inline.

On 18 Jul 2014, at 08:57, Tom Henderson <[email-masked]> 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:
> - 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.
> 

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.

So, from my point of view, there is a case for stable as well as for anonymous (i.e., variable) HITs/HIs.

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

> is odd as is the assertion that "web surfing" can use a

I am not aware of the criteria that were used for choosing the DHE groups. Can someone else comment on this?

> encryption option? (Haven't you finished testing yet:-)

I think this has been addressed on the mailinglist.

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

Is this maybe a specification hiccup?

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

> abstract - how many readers do we really expect to get

I suggest to simply remove the “SIGMA-compliant” in the abstract. It’s mentioned again (with a reference) later on in the introduction [5].

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

> for RSA. Isn't there better?

I am not sure what this is referring to.

BR
René

[1] http://tools.ietf.org/html/rfc6253
[2] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-5.2.9
[3] http://tools.ietf.org/html/draft-moskowitz-hip-dex-01#section-5.2.4
[4] http://tools.ietf.org/html/rfc7252#section-9.1.3.2
[5] http://tools.ietf.org/html/draft-ietf-hip-rfc5201-bis-14#section-1.2

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Tom Henderson <[email-masked]>
Date: Mon, 21 Jul 2014 15:50:42 -0700

Some more comments inline below:

On 07/21/2014 10:19 AM, Rene Hummen wrote:
>> regarding RFC5201-bis, so that we can have some list discussion.
>> See below (quoted verbatim from:
>> - what safeguards exist to reduce tracking of users? - questions
>> about the choices of certain algorithms and modes and whether they
>> are still current
>>
>> 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

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

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

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

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

---

From: Miika Komu <[email-masked]>
Date: Wed, 30 Jul 2014 12:59:19 +0300

Hi,

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

I think either way works.

> cites Schneier's Applied Cryptography book when referring to RSA.

IKEv2 refers to:

    [RSA]      Rivest, R., Shamir, A., and Adleman, L., "A Method for
               Obtaining Digital Signatures and Public-Key
               Cryptosystems", Communications of the ACM, v. 21, n. 2,
               February 1978.

    [PKCS1]    Jonsson, J. and B. Kaliski, "Public-Key Cryptography
               Standards (PKCS) #1: RSA Cryptography Specifications
               Version 2.1", RFC 3447, February 2003.