Dear WG, dear authors, dear SEC AD, As you have noticed, I had to remove HIP-DEX from this week telechat: partially because there were too many IETF drafts to be reviewed by the IESG this week (Area Directors are human beings 😉 ) but also because of some previously raised issues (IETF Last Call of 2020, ...) are not yet addressed.
Eric Rescola (in copy) has still two unaddressed points see below. Those points appear serious to me and should be fixed in a revised I-D if the WG/authors want to keep the RFC status of “proposed standard”. Lack of forward secrecy =================== The following text in section 1.2 (applicability) appears not to be fully correct: “Since the resulting "FS" key, likely produced during device deployment, would typically end up being used for the remainder of the device's lifetime. Since this key (or the information needed to regenerate it) persists for the device's lifetime, the key step of 'throw away old keys' in achieving forward secrecy does not occur, thus the forward secrecy would not be obtained in practice.” Eric Rescola’s suggestion: “... It is actually straightforward to get FS even under conditions where you do not do a new DH exchange by hashing the existing keys forward, as is done in TLS 1.3...”. Was this possibility analyzed for HIP DEX ? Eric also added the following: “...t still does not provide PFS and yet provides parameter choices that clearly underperform a PFS exchange with state of the art algorithms, at least in terms of computation (P-384 versus X25519). Absent some clear statement of the performance boundaries (as with done in LAKE) ...” and indeed the Lightweight Authenticated Key Exchange (LAKE) WG appears to also work in a constrained environment. “...However this document defines an array of algorithm choices, with the slower algorithms (P-384) being quite a bit slower than X25519, with the result that a PFS handshake with X25519 is probably as fast as a non-PFS handshake with P-384 if not faster (indeed almost as fast as one with P-256) which undercuts the argument that a non-PFS AKE is needed for performance. It's of course possible that there is some set of performance conditions in which non-PFS P-384 makes sense and which PFS X25519 does not, but this document does not provide analysis sufficient to draw that conclusion, and indeed the text in S 1.2, which focuses entirely on CPU, suggests the contrary....” Missing FOLD analysis ================== Eric Rescola: “... It still defines the unanalyzed FOLD algorithm without any real analysis demonstrating that it is secure in this context....”
_______________________________________________ Hipsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/hipsec
