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