Re: [Hipsec] Iotdir last call review of draft-ietf-hip-dex-11

[Miika Komu <[e-mail]>]

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.