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