Subject: [babel] WG adoption call for draft-do-babel-hmac (7/19 - 8/6)

From: Donald Eastlake <[email-masked]>
Date: Thu, 19 Jul 2018 08:46:37 -0400

This message begins a WG adoption call for draft-do-babel-hmac.
Since this starts during an IETF meeting, it is running for a bit
longer than usual, through August 6th. Please indicate whether you
think this draft should be adopted. Comments on the draft also
welcome.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Jul 2018 09:20:29 -0400

I think the document should be adopted—it addresses the use case about
which I care most: securing babel on homenets.

On Thu, Jul 19, 2018 at 8:46 AM, Donald Eastlake <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 19 Jul 2018 15:38:04 +0200

Donald Eastlake <[email-masked]> writes:

> This message begins a WG adoption call for draft-do-babel-hmac. Since
> this starts during an IETF meeting, it is running for a bit longer
> than usual, through August 6th. Please indicate whether you think this
> draft should be adopted. Comments on the draft also welcome.

I support adoption. As Juliusz quoted me saying in his slides, I found
the draft pleasant to read and straight forward to implement. And while
some more work is needed on the text, I don't think there are any
glaring deficiencies...

-Toke

---

From: "Russ White" <[email-masked]>
Date: Thu, 19 Jul 2018 09:41:42 -0400

> Since this starts during an IETF meeting, it is running for a bit longer than
> usual, through August 6th. Please indicate whether you think this draft should
> be adopted. Comments on the draft also welcome.

<wg cochair hat off>

Support.

/r

---

From: Dave Taht <[email-masked]>
Date: Thu, 19 Jul 2018 07:06:38 -0700

support.

-- 

Dave Täht
CEO, TekLibre, LLC
http://www.teklibre.com
Tel: 1-669-226-2619

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 19 Jul 2018 11:27:35 -0400

Ive read and support adoption of the HMAC draft.

Tim

On Thu, Jul 19, 2018 at 10:06 AM, Dave Taht <[email-masked]> wrote:

> longer than

---

From: David Schinazi <[email-masked]>
Date: Thu, 19 Jul 2018 14:10:04 -0400

I support WG adoption of draft-do-babel-hmac.
I found the document clear and the protocol simple.
I haven't implemented it yet, but look forward to doing so.

David

> On Jul 19, 2018, at 11:27, Tim Wicinski <[email-masked]> wrote:
> 
> On Thu, Jul 19, 2018 at 10:06 AM, Dave Taht <[email-masked] <mailto:[email-masked]>> wrote:
> support.
> On Thu, Jul 19, 2018 at 6:41 AM Russ White <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
> 
> 
> 
> -- 
> 
> Dave Täht
> CEO, TekLibre, LLC
> http://www.teklibre.com <http://www.teklibre.com/>
> Tel: 1-669-226-2619
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/babel <https://www.ietf.org/mailman/listinfo/babel>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 19 Jul 2018 20:52:17 +0000

> > draft should be adopted. Comments on the draft also welcome.

I support.
Barbara

---

From: Gabriel Kerneis <[email-masked]>
Date: Mon, 23 Jul 2018 14:18:37 +0200

> think this draft should be adopted. Comments on the draft also

I support adoption of this draft.

Gabriel

---

From: Antonin Décimo <[email-masked]>
Date: Mon, 23 Jul 2018 17:25:04 +0200

On Thu, 19 Jul 2018 14:46:37 +0200,
> think this draft should be adopted. Comments on the draft also

I support the adoption.

--
Antonin Décimo

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 29 Jul 2018 01:35:18 +0300

I have read the draft and support adoption.

That said..nit or two :-)

   Whenever B resets its PC, or whenever B doesn't know whether
   its PC has been reset, it picks an index that it has never used
   before (either by drawing it randomly or by using a reliable hardware
   clock) and starts sending PCs with that index.

I think there are 3 potential sources for index:

- nvram/flash (truly unique, frequently but not always available)
- magic timestamp (e.g. GPS, magical secure NTP might give us ~unique timestamp, or RTC that never goes backward for this purpose.. but typical routers do not have strictly monotonic hardware clocks the text notes)
- something pseudorandom that has sufficiently low collision likelihood given the number of bits of index

so I think the text (and some of the following) is slightly optimistic. I would probably just settle for a sufficiently low collision chance.

Also, I would like to have byte(/few bits) somewhere indicating the algorithm used for HMAC. Maybe I’m just tired and can’t see one that is already there.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 29 Jul 2018 00:53:47 +0200

> That said..nit or two :-)

We're listening.

> so I think the text (and some of the following) is slightly
> optimistic. I would probably just settle for a sufficiently low
> collision chance.

So I just need to add "likely", as in "likely not used before"?  Or are
you suggesting something more?

> Also, I would like to have byte(/few bits) somewhere indicating the
> algorithm used for HMAC. Maybe I’m just tired and can’t see one that is
> already there.

There's none.  The procedure is:

  - receiver computes HMAC for each algo/key pair it has been provisioned with;
  - it does a bytewise comparison of the result of each key computation
    with each HMAC computed in the packet.

So the receiver doesn't need to know the algorithm used by the sender --
it only needs to know which algorithm is associated to each of the keys it
has been provisioned with.

Am I missing something?  What purpose would adding info about the
algorithm to the on-the-wire HMAC serve?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 29 Jul 2018 09:08:17 +0300

> you suggesting something more?

Nah, just wording changes here and there (there are few places that assume the options 1/2 which are not realistic always).

> algorithm to the on-the-wire HMAC serve?

Ah, nevermind, I was still in the mindset with the key id actually on the wire (that’s what I get for rereading drafts at night). Without it, as I reread section 4.3, algorithm does not have to be either. So it is fine as it stands.

That said, this design leads to N times more efficient CPU DOS (non-accelerated SHA256 on slow CPU times MTU worth of HMACs = quite a lot of computation on low-end devices). Then again, I am not sure it really matters (and implementation can constrain that as they want to anyway).

Cheers,

-Markus

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 29 Jul 2018 09:10:00 +0300

> That said, this design leads to N times more efficient CPU DOS (non-accelerated SHA256 on slow CPU times MTU worth of HMACs = quite a lot of computation on low-end devices). Then again, I am not su…

Not even that actually, as long as you keep reasonably low number of keys on a device (ideally only one); it will calculate hmacs only for # of keys _it has_, not # of HMAC TLVs in packet.

I think I left my brain on vacation :-)

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 29 Jul 2018 12:40:56 +0200

>> That said, this design leads to N times more efficient CPU DOS
>> (non-accelerated SHA256 on slow CPU times MTU worth of HMACs = quite
>> a lot of computation on low-end devices). Then again, I am not sure it
>> really matters (and implementation can constrain that as they want to
>> anyway).

> Not even that actually, as long as you keep reasonably low number of
> keys on a device (ideally only one);

Exactly.  Section 1.1 says

    The protocol is inapplicable in situations where [...] large numbers
    of trusted keys are provisioned on a single link at the same time.

and Section 4.3 says

    The HMAC of the packet MUST NOT be computed for each HMAC TLV
    contained in the packet, but only once for each configured key.

I'll see if it can be made clearer.

That being said -- Denis Ovsienko and David Schinazi have suggested that
the HMAC should be associated with a key-id, a small integer that allows
matching provisioned keys with in-packet keys.  I'm not a big fan, but I'm
willing to add it to the document if people feel strongly about it.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sun, 29 Jul 2018 14:04:13 +0300

> On 29 Jul 2018, at 13.40, Juliusz Chroboczek <[email-masked]> wrote:

I think I prefer the current scheme - the most common case should be exactly 1 key anyway, and corner case ‘few’ keys (either during key roll-over, or at some trust domain cross-over point).

-Markus