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. 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? > (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. > 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? > (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: 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. > - 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. 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/
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
