Re: [babel] Some open HMAC issues

[Juliusz Chroboczek <[e-mail]>]

>> you need to pick a KeyID that is currently unused.

> I don't see why. Having a KeyID conflict just means you'll try both keys.

Ah, that's the bit that I was missing -- you allow multiple keys with the
same ID.  So the UI issue goes away -- you just set the KeyID to 0 by
default.  And an implementation is free to ignore KeyIDs on reception.

I lift my opposition.  If the WG wants KeyIDs, and provides me with
suitable text to put in the spec, I'll implement them.  In which case
I reserve the right to make sarcastic comments in public.

> An implementation is free to always send KeyID as 42 and silently drop
> any HMAC TLV KeyID that isn't 42 if it can't handle the complexity.

Nah, you just check all keys, ignoring their KeyID.  In other words, the
KeyID degenerates to a field that "may be ignored on reception".

> In homenet there was discussion of pairwise symmetric keys
> distributed via HNCP.

That's not what the protocol was designed for.  We send one HMAC per key
in every freaking packet, and if we've got more than 60 or so, we'll quite
simply run out of space in the Ethernet frame.  All keys, no data, the
drunken cryptographer's dream.

If you want pairwise keying, use a protocol that uses pairwise communication.
Also known as unicast.  I hear you're the co-author of just such a protocol.

-- Juliusz