Subject: [babel] WG Last Call on draft-ietf-babel-hmac

From: Donald Eastlake <[email-masked]>
Date: Thu, 20 Dec 2018 23:49:55 -0500

Hi,

At the Bangkok IETF meeting we said we would start a WG Last Call on
draft-ietf-babel-hmac. So, this message starts such a Last Call. Due
to the holidays, this will run through January 13th. Do you think this
draft is ready for publication? It is fine to provide suggestions for
improvement with your response.

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

---

From: Dave Taht <[email-masked]>
Date: Fri, 21 Dec 2018 06:46:44 -0800

I am sufficiently old fashioned to want to wait for two interoperable
implementations and some field deployment experience before finalizing
this document. I would like key rotation to work, and, although it may
not be right for this document, the key format as expressed to users,
solidified. Treating 0xdeadbeef as a string vs deadbeef as a string
results in very different keys.

Nits:

"The protocol
   is inapplicable in situations where asymmetric keying is required,
   where the trust relationship is partial"

Given my confusion on this I suggest:

"The protocol
   is inapplicable in situations where asymmetric keying is required,
   where the trust relationship per interface is partial"

...

"and it does not require any
   form of persistent storage."

I would just strike this claim, because it does. While in one
embodiment (hnet) it is possible to bootstrap keys, in most others you
need a routing protocol running before you can dynamically ship conf
files or dynamic configuration to the ends of the network.

"per-interface 32-bit
   integer known as the "packet counter" (PC)."

Do we have the blessing of a cryptographer type saying just how secure
this and the nonce and index are? I don't use words like
"invulnerable" lightly, rather I would say the probability is X of Y.
Given the number of fixed, known fields in the shortest possible hello
message...

...

"Every implementation MUST implement HMAC-SHA256
   [RFC6234], and MAY implement other HMAC algorithms.

I think we managed to get blake2s up to a SHOULD in the past weeks. :)

"Every implementation MUST implement HMAC-SHA256
   [RFC6234], SHOULD implement blake2s, and MAY implement other HMAC algorithms.

or

"SHOULD implement two or more IETF-approved HMAC algorithms".

...

"if the PC
      overflows, a new index is generated;"

"*When* the PC overflows", not if.

And overflow + new index generation is one of those things that
implementors MUST test.

I'm not not huge on the word "index", as used throughout, as in most
programming contexts that's usually a 32 bit integer. Secondary Nonce?

...

"can
   be fairly large (up to 192 octets)"

"There MUST be a minimum size defined for the nonce and index of" (go
drinking with a good cryptographer).

Otherwise implementors will use a single byte.

...

7.  IANA Considerations

Has anyone gone to iana so these tlvs can be baked in stone?

...

Toke Hoyland-Jorgensen

do we have utf-8 support in rfcs yet?

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 21 Dec 2018 21:07:34 +0100

> do we have utf-8 support in rfcs yet?

Heh, yeah. Also, my name is spelled with an i, not a y, regardless of
the encoding ;)

-Toke

---

From: David Schinazi <[email-masked]>
Date: Sat, 22 Dec 2018 03:31:47 -0800

I personally believe the HMAC document is ready for publication.

I think Dave's points about key rotation and config file format are
interesting, but I see them as implementation details that do not
necessarily belong in the IETF spec.

David

On Fri, Dec 21, 2018 at 12:07 PM Toke Høiland-Jørgensen <[email-masked]>
wrote:

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 22 Dec 2018 16:17:26 +0100

> interesting, but I see them as implementation details that do not necessarily
> belong in the IETF spec.

I agree.

However, I have one nit against both HMAC and DTLS which I'll write up on
the list ASAP.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Sun, 23 Dec 2018 15:11:54 +0100

>    [RFC6234], SHOULD implement blake2s, and MAY implement other HMAC algorithms.

+1 on this, BTW :)

> ....

And yeah, this would be useful to have set before I submit the Bird
patch upstream.

-Toke

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 23 Dec 2018 21:14:26 +0100

Hi Dave, and thanks for your comments.

> "and it does not require any form of persistent storage."

> files or dynamic configuration to the ends of the network.

I've clarified that.

(The claim here is that there is no storage necessary for indices and
seqnos -- indices and seqnos can be discarded when a router reboots, at
the cost of a mere RTT of lost data (the time needed for a challenge).  Of
course, persistent storage is needed for storing keys.)

> "per-interface 32-bit integer known as the "packet counter" (PC)."

> this and the nonce and index are?

What do you mean?

> I think we managed to get blake2s up to a SHOULD in the past weeks. :)

Yep.

> "Every implementation MUST implement HMAC-SHA256 [RFC6234], SHOULD
>    implement blake2s, and MAY implement other HMAC algorithms.

Yep, but with a precise reference (chapter and verse).

> "SHOULD implement two or more IETF-approved HMAC algorithms".

Nope.  The IETF is not in the business of approving HMAC algorithms.

> "if the PC overflows, a new index is generated;"

> "*When* the PC overflows", not if.

I'm not sure what your point is.  A PC overflow will happen once in
4 billion Babel packets.  With reasonable parameters, that's once in a few
hundred years.

> And overflow + new index generation is one of those things that

If an implementation is buggy, it will become unreachable after a few
hundred years without a reboot.  I'm not too worried.

> programming contexts that's usually a 32 bit integer. Secondary Nonce?

It was originally the "sender's nonce", but David pointed out it's not
a nonce (it's used multiple times).  I then suggested "tag", but David
pointed out that the term "tag" has a different meaning in a security
context.

Index is unusual, granted, but it makes sense: the protocol relies on
having multiple sequences of PCs, and the index identifies the PC sequence
we're in right now -- think of it as indexing a (virtual) table of PC
sequences.

> drinking with a good cryptographer).

You don't need a cryptographer, it's a rather trivial probability
computation.  Advice is given in the third paragraph of the Security
Considerations section.

> Otherwise implementors will use a single byte.

If an implementation never loses its PC (e.g. because it has a reliable
hardware clock), size 0 indices make perfect sense.

For nonces, you need to make sure that a nonce is never reused for a given
(key, source, destination) triplet.  If you have reliable persistent
state, then you can use a counter that is set to 0 whenever you rekey.
The counter can be encoded in the minimum number of octets necessary, and
hence when the counter is 0, a 0-byte nonce makes perfect sense.

In short, 0-byte indices and nonces make perfect sense, and I'm opposed to
fixing a minimum size.

> Has anyone gone to iana so these tlvs can be baked in stone?

Donald?

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 23 Dec 2018 21:16:10 +0100

> Heh, yeah. Also, my name is spelled with an i, not a y, regardless of

That changes your position in the alphabetic ordering in the
Acknowledgements section ;-)

Fixed, sorry for that.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 23 Dec 2018 21:36:15 +0100

> I think we managed to get blake2s up to a SHOULD in the past weeks. :)

   Every
   implementation MUST implement HMAC-SHA256 as defined in [RFC6234] and
   Section 2 of [RFC2104], SHOULD implement keyed BLAKE2s [RFC7693], and
   MAY implement other HMAC algorithms.

Ok?

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 23 Dec 2018 22:40:30 +0100

>> Has anyone gone to iana so these tlvs can be baked in stone?

I just have.  IANA #1133140.

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 24 Dec 2018 23:06:27 +0100

> Acknowledgements section ;-)

Woohoo, number one! :D

> Fixed, sorry for that.

Thanks :)

-Toke

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 Dec 2018 23:05:55 -0500

The TLV Type code point have been approved and should get allocated soon.

Thanks,
Donald

---

From: Dave Taht <[email-masked]>
Date: Tue, 25 Dec 2018 20:36:20 -0800

> > Acknowledgements section ;-)

I was actually serious about the utf-8 thing. As it's been 15 years
since utf-8 became an internet standard
(https://tools.ietf.org/html/rfc3629) it would be nice if internet
standards could be written in utf-8.

When last I checked on this, 5 years back, tools were "almost" ready.

--
Dave Täht