Hi, (Robert, please double check if you agree with my comments) su, 2019-11-24 kello 22:38 -0800, Michael Richardson via Datatracker kirjoitti: > Reviewer: Michael Richardson > Review result: Ready > > I am the assigned IoT-Directorate reviewer for 1draft-ietf-hip-dex > I reviewed the -11 version. > > I did not identify any technical problems or gaps. > The introduction tells that I won't understand this without a good > understanding of RFC7401 (HIPv2). I went ahead anyway, given that I > did know > HIPv1 (RFC5201) and IKEv2. > > While it is clear that I could not implement without knowing 7401, I > did find > that I could understand most of the goals, the compromises that were > made to > reduce the complexity for constrained environments. I did go back > and read > 7401 in the end to fill in a few gaps. > > Particularly I really needed to understand RFC7343 HITs of the new > type, and > I did not manage to understand that part. let us know if we should clarify something particular in the DEX draft. > I observe that a new ECDH type of > HIT is defined, but I did understand how these values would be > exchanged/stored or looked up. > I would appreciate a use case or two which has been sufficiently > built-out so > that I can see the whole picture. If ECDH HITs come from DNS (via > AAAA > records) for instance, then I'd appreciate an understanding if/how > the > constrained device is able to leverage DNSSEC. not really AAAA records, but rather "HI" records, so actually the public key is stored in the DNS as defined in RFC8005. Nothing prevents using DNSSEC except the capabilities of the device. I don't know the footprint of a minimal DNSSEC implementation at the client side... > In particular, I'd like to know what kind of applications are ruled > out by > lack of PFS, this is a rather generic question and I don't know if some researched and created a taxonomy of applications that fit PFS. So I don't really have a good answer for this but just a couple of easy answers: * If the data is of emphemeral nature (useful only at the very present), then PFS may not be necessary. * If the hardware too is too constrained, then non-PFS security is better than no security. > and if a kind of PFS can be restored by rotating HITs in DNS. really interesting, how would this work in practice? (Usually it's just the server's HITs stored in the DNS so perhaps just extra security measure for the server?) > Would this document play well with draft-ietf-ipsecme-implicit-iv? BEX and DEX can be used with any data plane security, but ESP is commonly used, so I don't really see why not. Saving bits on the wire for the data plane in contrained scenarios is always good. Robert what do you think? > I am unclear if the diet nature of DEX is more about: > (1) constrained/challenged networks > (2) constrained/slow CPUs > (3) systems with very minimal amounts of flash I haven't been involved with this work since the beginning, so perhaps Robert should comment on this more but here's my interpretation. I believe the priority is on slow CPUs and flash comes as the second. Network is the last one in the priority list; if you check the origins of the work, for instance, the "Slimfit" approach compresses HIP messages much better. RFC7228 section 3 lists different classes of IoT devices but it's mostly related to the memory dimension. I am not sure if have classifications for the network/CPU dimensions in IETF... > (1) networks have often very small packet sizes, and I would > appreciate > understanding the total frame sise of each I1/R1/I2/R2, and any > impact that > fragment assembly might have on the statelessness of the I1/R1 > exchange. according to Hummen et al, "Slimfit - A HIP DEX Compression Layer for the IP-based Internet of Things", DEX packets sizes were roughly as follows in an earlier version of the draft (draft-moskowitz-hip-dex- 00): I1: 48 bytes R1: ~184 bytes I2 ~232 bytes R2: ~86 bytes > I know that HIP has be profiled for use in 802.15.9, and I assume > that HIP > DEX is even better, but the lack of PFS might be a show stopper. Quoting Eric Vyncke: "I had a conversation with Ben Kaduk today at the hackathon. While Ben had reviewed the DEX document about 2 years ago, he was clear that PFS is a requirement for IETF standard _EXCEPT_ (and this is important): 1) the text is clear that there is no PFS property in DEX 2) there is a justification why PFS was not implemented (such as defining a specific use case)." Regarding to the use case, Robert sent the following text proposal earlier: HIP DEX, by design does not support Perfect Forward Secrecy (PFS). All current PFS approaches use Ephemeral DH, secured and identified in some manner (e.g. SIGMA or PAKE). There are classes of devices, like those based on the 8051 microprocessor where this is prohibitably expensive. Experience with the ZWAVE ZW0500 found that EC25519 key pair generation exceeded 10 seconds with unacceptable battery consumption. The ECDH wide-multiply of the static-static keys was taking 8 - 9 seconds with measurable battery drain. For these class of devices, the possible risk of no PFS has to be weighed against the risk of theft of preshared keys alternatives. Also if is often the case that HIP DEX is only performed during device join time, and thus no PFS is considered an acceptable compromised. HIP DEX MUST only be used in communicating with such constrained devices. > (2) slow/sleepy CPUs are not going away, but the amount of available > flash on > rather cheap, small and sleepy devices is now in the multiple > megabytes, so > it is unclear if further code simplications are worthwhile. Agree on the cheapness of memory but I believe the restrictions are leaning more towards CPU. > My questions should not stop the document from advancing. Thanks for you feedback. It is a bit unclear to me how to reflect this discussion the draft, so please comment explicitly if you think something should be added there. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
