Subject: [babel] Some news about HMAC

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 28 Jun 2018 23:39:19 +0200

The previous thread might be overwhelming to some, so let me summarise.
My personal understanding, of course, not necessarily representing WG
consensus.

We've got a new HMAC protocol, heavily based on Denis Ovsienko's work but
significantly reworked by Clara Dô, Weronika Kołodziejak and myself with
important ideas due to Markus Stenberg and David Schinazi, and significant
input from Toke Høyland-Jørgensen and a colleagues here in Paris (Florian
Horn).  I think everyone involved is convinced the protocol is not
vulnerable to replay even in the absence of a hardware clock or persistent
storage.

There are three variants:

  - the Do-Kołodziejak-Chroboczek variant, that uses an explicit tag
    ("nonce") in every packet;
  - the Stenberg variant, that only encodes the tag in the challenge
    response, and then makes it explicit;
  - the Schinazi variant, which combines the tag with the packet counter.

We've had a telephone chat with David, and we've come up with the
following:

  - the Schinazi variant doesn't buy us much, and is more difficult to
    explain; David can live with the DKC variant;
  - the term "sender's nonce" is badly chosen, David suggests "index", but
    I'm thinking about using "tag"; the receiver's nonce remains a nonce;
  - both David and I prefer the more explicit DKC variant, but we're still
    looking at the Stenberg variant.

The plan is to implement and document the DKC variant, and then put the
discussion to the list.  At any rate, the implementation should be easy to
convert to the Stenberg style if that's what the WG settles on.

Clara and Weronika are telling me that the new protocol is easier to
implement than Denis' original proposal, and requires fewer changes to
babeld.  Their code is mostly complete, but they've still got some bugs,
and it's late.  We'll try to publish the implementation tomorrow, but no
promises.

(Thanks to Clara and Weronika, by the way, for agreeing to redo all of
their code with a new protocol just three days before the official end of
their internship.  That would not have been possible without the moral and
especially culinary support of the local Lebanese-Iranian food shop.)

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 28 Jun 2018 15:56:15 -0700

I agree with Juliusz's summary.

I like the DKC variant, it has slightly less configuration knobs than mine
but it reduces complexity which is a good tradeoff.

I'll try to find time to implement it before Montreal.

The Stenberg variant makes me uneasy because it loses the property
of completely ignoring any message with a bad MAC, and that opens
up our attack surface to parser bugs.

Regarding terminology, I prefer "index" to "tag" because "tag" makes
me think about "authentication tag" which is how some protocols
refer to the MAC, and we also have a MAC in this protocol.
But I can live with "tag", it's better than "nonce".

Great work Clara and Weronika, congratulations!

David

> On Jun 28, 2018, at 14:39, Juliusz Chroboczek <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 29 Jun 2018 03:04:19 +0200

>     response, and then makes it explicit;

This sentence makes no sense.  Sorry.

In the Stenberg variant, the index (or tag, or sender's nonce) is only
sent in the Challenge Response.  In later packets, it is hashed as part of
the pseudo-header, but not sent explicitly, on the assumption that the
receiver has saved it during the challenge.

The advantage is that the index does not need to be sent in every packet,
saving 10 octets per packet or so.  The disadvantage is that upon an HMAC
failure the receiver has no way to distinguish between a spoofed packet
and a sender reset, and must therefore send a challenge unconditionally.

Unlike David, I rather like the Stenberg variant, but I need to think the
implications through.  For now, we're implementing the DKC variant, and
we'll do the thinking later.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Thu, 28 Jun 2018 18:08:09 -0700

> On Jun 28, 2018, at 18:04, Juliusz Chroboczek <[email-masked]> wrote:
> 

I didn't say I didn't like it. I actually think it's very clever.
It's just the property that we lose because of it that makes me uneasy.

David