Subject: [babel] HMAC: removed constraint on the key stored in interface table

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Aug 2019 17:40:38 +0200

Dear Barbara,

I have removed from draft...hmac the requirement for the key that is
stored in the interface entry for being equal to the block size of the
hash.  This means that you need to put this requirement in the information
model.

After thinking it over, I don't think it's part of the HMAC protocol,
since it's not visible on the wire.  It's purely a management issue, and
thus should be in the management document.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 18:03:47 +0000

> I have removed from draft...hmac the requirement for the key that is stored
> in the interface entry for being equal to the block size of the hash.  This
> means that you need to put this requirement in the information model.
> 
> After thinking it over, I don't think it's part of the HMAC protocol, since it's
> not visible on the wire.  It's purely a management issue, and thus should be
> in the management document.

But this brings us back to the problems that prompted this text in the hmac draft. Where the Bird implementation manipulated the input "key" according to the HMAC RFC (which defined several different things that it called a "key", IIRC) -- and this was unexpected and would not have interoperated with the babeld implementation (the two implementations would send different bits on the wire, given the same input key). Somehow, I need to be sure that for a given input key, I'll always get the same output on the wire, no matter which Babel implementation I'm inputting the key to. 

The information model is not normative for babel-hmac. So info model cannot impose any input condition or constraint on a babel-hmac implementation, related to what values can be expected for a key. The Bird implementation allowed someone to enter the key through a GUI.

This is a major proposed change that can lead to non-interoperability.

I think it would also make Dave Taht unhappy. You don't want to make Dave unhappy, do you?
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Aug 2019 20:53:29 +0200

>> hash. [...]  It's purely a management issue, and thus should be in the
>> management document.

> But this brings us back to the problems that prompted this text in the
> hmac draft.

The problem is that this constraint is not normatively enforceable.

The point is that this normalisation property is never used in the (H)MAC
draft -- it appears there as a completely arbitrary requirement on the
conceptual data structures that has no effect on what bits are sent on the
wire.  Since the data structures are conceptual, an implementation is
allowed to use any other representation that leads to the same on-the-wire
result.  In the words of RFC 6126bis:

    This description is conceptual: a Babel speaker may use different data
    structures as long as the resulting protocol is the same as the one
    described in this document.

What I'm suggesting is that you add something to the following effect to
the description of babel-mac-key-value:

  In the case where babel-mac-key-algorithm specifies an algorithm based
  on the HMAC construction, then this value MUST be the exact size of the
  hash's block size (i.e. it has already undergone any preprocessing, such
  as the hashing or zero extension described in Section 2 of RFC 2104).

> This is a major proposed change that can lead to non-interoperability.

I don't see how.  The end result is the same; the only difference is that
now the normalisation is allowed to happen in the management interface.

> I think it would also make Dave Taht unhappy.  You don't want to make

It sometimes takes a tough man to make a tender chicken.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 20:35:05 +0000

> What I'm suggesting is that you add something to the following effect to the
> description of babel-mac-key-value:
> 

So the way I interpret this is the only HMAC key length I can reliably expect all implementations to treat the same, is a key the same length as the hash block size.
Is there any rule for Blake2s keys? I see from RFC7693 that a Blake2s key can be 0 <= kk <= 32. The RFC tells the implementation to zero-pad keys less than 32 bytes.

So do I maybe have a rule that
 - for algorithms based on HMAC construction, the key MUST be the exact size of the block size. For HMAC-SHA256, this is defined in RFC4868 as 64 bytes.
 - for algorithms with specifications that unambiguously define allowed key length, the key MUST be the maximum length allowed by the specification. For Blake2s, this is defined in RFC7693 as 32 bytes.
 - for other algorithms, the key MUST be the maximum key length that can be provided such that the implementation will not zero-pad or otherwise manipulate the key prior to use.
?

Or maybe I just say:
The key MUST be the maximum key length that can be provided such that the implementation will not zero-pad, truncate, or otherwise manipulate the key prior to use. For HMAC-SHA256, this is defined in RFC4868 as 64 bytes. For Blake2s, this is defined in RFC7693 as 32 bytes.
?
Barbara

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 13 Aug 2019 23:58:09 +0200

>> the description of babel-mac-key-value: In the case where
>> babel-mac-key-algorithm specifies an algorithm based on the HMAC
>> construction, then this value MUST be the exact size of the hash's block
>> size (i.e. it has already undergone any preprocessing, such as the
>> hashing or zero extension described in Section 2 of RFC 2104).

> Or maybe I just say: The key MUST be the maximum key length that can be
> provided such that the implementation will not zero-pad, truncate, or
> otherwise manipulate the key prior to use. For HMAC-SHA256, this is
> defined in RFC4868 as 64 bytes. For Blake2s, this is defined in RFC7693 as
> 32 bytes.  ?

We have at least three reasonable options.

1. Deterministic:

  - for HMAC based algorithms, the key is exactly the block size (64 bytes
    for HMAC-SHA256);
  - for Blake2s, it is exactly 32 bytes.

This is deterministic, but not very convenient for the user (the user
needs to do zero-pad himself).  The behaviour is suprising to the user,
especially in the case of Blake2s.

2. Consistent:

  - for HMAC based algorithms, the key is at most the block size (64 bytes
    for HMAC-SHA256), and is zero-padded as described in Sectin 2 of RFC 2104;
  - for Blake2s, it is at most 32 bytes.

This makes behaviour coherent between HMAC and Blake2s, in both cases any
size of key is allowed up some maximum.  This is convenient for the user
(who can use shorter keys), and reasonably deterministic -- the only
operation performed on the key is zero-padding.  It also doesn't use the
hashing defined in RFC 2104, which is not a good idea (you should be using
a proper KDF instead, and be doing the transformation offline).

3. Beaurocratic:

  - for HMAC based algorithms, the key is an arbitrary size, and is either
    zero-padded or hashed as described in Section 2 of RFC 2104;
  - for Blake2s, it is at most 32 bytes.

This has the advantage of obeying the RFCs.  It has the flaw of being
inconsistent (long keys are only accepted for HMAC), and of encouraging
a practice that is insecure (the hashing from RFC 2104).

I have a weak preference for (2), but can live with (3).  I realise it
contradicts what I advocated earlier.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 22:26:39 +0000

> >> What I'm suggesting is that you add something to the following effect
> >> to the description of babel-mac-key-value: In the case where
> >> construction, then this value MUST be the exact size of the hash's
> >> block size (i.e. it has already undergone any preprocessing, such as
> >> the hashing or zero extension described in Section 2 of RFC 2104).
> 
> > Or maybe I just say: The key MUST be the maximum key length that can
> > be provided such that the implementation will not zero-pad, truncate,
> > or otherwise manipulate the key prior to use. For HMAC-SHA256, this is
> This is deterministic, but not very convenient for the user (the user needs to
> do zero-pad himself).  The behaviour is suprising to the user, especially in the
> case of Blake2s.

The info model doesn't describe the user interface. We're describing the bits that get delivered to the babel-mac implementation. What do you want to see as an input to a babel-mac implementation?

> This makes behaviour coherent between HMAC and Blake2s, in both cases
> any size of key is allowed up some maximum.  This is convenient for the user
> hashing defined in RFC 2104, which is not a good idea (you should be using a
> proper KDF instead, and be doing the transformation offline).

This would work if the babel-mac implementation were willing to do the zero-padding. But not if you want zero-padding done before delivery to babel-mac.
 
> inconsistent (long keys are only accepted for HMAC), and of encouraging a
> practice that is insecure (the hashing from RFC 2104).

This is just confusing, because it's not describing what goes across the wire. It seems the intent of this is that for HMAC-SHA256, the key that gets delivered to babel-mac is max of 64 bytes. So it devolves to case 2. And if cases 2 and 3 are really expecting the zero-padding to be included in what gets delivered, then both devolve completely back into case 1.

If Case 1 is what you want delivered to babel-mac, but you want some UI niceness expressed, I can add a statement like "If keys are generated from user input, the user interface or management system is expected to zero-pad strings that are less than the required length, and prohibit strings longer than the required length. This ensures the delivered string is exactly the required number of bytes." This would effectively provide Case 2, but with the zero-padding in what gets delivered to babel-mac.
Barbara
 
> I have a weak preference for (2), but can live with (3).  I realise it contradicts
> what I advocated earlier.
> 
> -- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Aug 2019 15:31:20 -0700

I think we may be overly constraining ourselves here. How about:

- Keys used for Babel-MAC MUST be of a length suitable for that MAC
function.
- Implementations MUST reject keys that are not suitable for the MAC
function; in other words, implementations MUST NOT preprocess keys of
unsuitable lengths to produce a key of suitable length.
- Babel management interfaces MUST NOT allow configuring keys of non
suitable lengths.
- Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be
32 bytes long.

David

On Tue, Aug 13, 2019 at 3:26 PM STARK, BARBARA H <[email-masked]> wrote:

> needs to
> The info model doesn't describe the user interface. We're describing the
> bits that get delivered to the babel-mac implementation. What do you want
> to see as an input to a babel-mac implementation?
>
> >
> > 2. Consistent:
> >
> This would work if the babel-mac implementation were willing to do the
> zero-padding. But not if you want zero-padding done before delivery to
> babel-mac.
>
> > 3. Beaurocratic:
> >
> This is just confusing, because it's not describing what goes across the
> wire. It seems the intent of this is that for HMAC-SHA256, the key that
> gets delivered to babel-mac is max of 64 bytes. So it devolves to case 2.
> And if cases 2 and 3 are really expecting the zero-padding to be included
> in what gets delivered, then both devolve completely back into case 1.
>
> If Case 1 is what you want delivered to babel-mac, but you want some UI
> niceness expressed, I can add a statement like "If keys are generated from
> user input, the user interface or management system is expected to zero-pad
> strings that are less than the required length, and prohibit strings longer
> than the required length. This ensures the delivered string is exactly the
> required number of bytes." This would effectively provide Case 2, but with
> the zero-padding in what gets delivered to babel-mac.
> Barbara
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Tue, 13 Aug 2019 23:01:35 +0000

See response to Juliusz. The info model is *not* designing a user interface. It is stating what it will (or is allowed to) deliver to the babel implementation. What happens to generate the bytes that get delivered to babel by the info model are outside the control of the info model (so normative language is no good). Those proposed SHOULD statements mean the info model really can deliver pretty much any string to a babel implementation and expect interoperable results. I don’t think that’s true.
Barbara

From: David Schinazi <[email-masked]>
Sent: Tuesday, August 13, 2019 6:31 PM
To: STARK, BARBARA H <[email-masked]>
Cc: Juliusz Chroboczek <[email-masked]>; [email-masked]
Subject: Re: [babel] HMAC: removed constraint on the key stored in interface table

- Keys used for Babel-MAC MUST be of a length suitable for that MAC function.
- Implementations MUST reject keys that are not suitable for the MAC function; in other words, implementations MUST NOT preprocess keys of unsuitable lengths to produce a key of suitable length.
- Babel management interfaces MUST NOT allow configuring keys of non suitable lengths.
- Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be 32 bytes long.

David

_______________________________________________
babel mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/babel<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_babel&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=JZ7xlM2Cp9Qum1nJdQ0KGOuvIrbDvjkdk_y5kD1zv-4&s=m-rBfp2Ihu3LDKOtK9MXUZJd-5yL7XSOArJJ8Oy4wsI&e=>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2019 01:06:41 +0200

> bits that get delivered to the babel-mac implementation. What do you
> want to see as an input to a babel-mac implementation?

Options (1) and (2) are trivial to implement on the fly.  Option (3)
requires precomputing the hash of the key, which adds a field to a data
structure somewhere (unless you discard the provided key and replace it
with its hash, which for some reason I find distasteful).

Option (1):

  if(key->length != 64)
      return -1;
  ...
  for(i = 0; i < 64; i++)
      ibuf = key->value[i] ^ 0x36;

Option (2):

  if(key->length > 64)
      return -1;
  ...
  for(i = 0; i < key->length; i++)
      ibuf = key->value[i] ^ 0x36;
  memset(ibuf + key->length, 0x36, 64 - key->length);

The UI of babeld currently implements option (2).  Having the UI and the
information model be congruent gives me a nice, warm feeling.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2019 01:13:32 +0200

> See response to Juliusz. The info model is *not* designing a user interface. It
> is stating what it will (or is allowed to) deliver to the babel implementation.
> What happens to generate the bytes that get delivered to babel by the info
> model are outside the control of the info model (so normative language is no
> good). Those proposed SHOULD statements mean the info model really can deliver
> pretty much any string to a babel implementation and expect interoperable
> results.

If I read Barbara right:

  - administrator writes a script that configures his 10000 routers the way
    he likes it;
  - administrator buys a new router that interprets the data model differently;
  - script breaks because the new router requires exactly 64 bytes in a key;
  - administrator spends the weekend fixing his network rather than going
    hiking with his children as he promised.

Think of the children, David.

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Tue, 13 Aug 2019 16:42:30 -0700

@Juliusz: Revised statement, now with 30% more thinking of the children:

(only added second normative statement)

- Keys used for Babel-MAC MUST be of a length suitable for that MAC
function.
- Implementations MUST accept all key lengths that are suitable for the
selected MAC function, as defined by the specification of that MAC function.
- Implementations MUST reject keys that are not suitable for the MAC
function; in other words, implementations MUST NOT preprocess keys of
unsuitable lengths to produce a key of suitable length.
- Babel management interfaces MUST NOT allow configuring keys of non
suitable lengths.
- Keys for HMAC-SHA256 SHOULD be 64 bytes long, keys for Blake2s SHOULD be
32 bytes long.

@Barbara: I'm not discussing the user interface, only what the information
model can deliver to the Babel implementation

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 14 Aug 2019 14:37:15 +0000

I’m unclear – which “implementation” are we talking about? A babel-mac implementation or a data model?

I still think I would prefer something in info model like (the Courier font is existing text):

      The value of the HMAC key.  An implementation MUST
      NOT allow this parameter to be read.  This can be done by always
      providing an empty string when read, or through permissions, or other means.
      This value MUST be provided when this instance is created, and is
      not subsequently writable. The key length MUST be the maximum length that is
              defined for the associated babel-mac-key-algorithm, so there is no need for the MAC algorithm to zero-pad,
              truncate, or otherwise manipulate the key prior to use. For HMAC-SHA256, this is defined
              in RFC4868 as 64 bytes. For Blake2s, this is defined in RFC7693 as 32 bytes. If keys are
              generated from user input, the user interface or management system is expected to
              zero-pad strings that are less than the required length, and prohibit strings longer than
              the required length. This ensures the delivered string is exactly the required number of bytes.

I really dislike SHOULDs and wiggle room in things like this that can cause a complete breakdown of interoperability. Hashing is an area where it’s very easy to achieve non-interoperability.
Barbara

- Implementations MUST accept all key lengths that are suitable for the selected MAC function, as defined by the specification of that MAC function.

@Barbara: I'm not discussing the user interface, only what the information model can deliver to the Babel implementation

If I read Barbara right:

-- Juliusz

---

From: David Schinazi <[email-masked]>
Date: Wed, 14 Aug 2019 10:15:43 -0700

Thanks Barbara!

I meant Babel-MAC implementations.

Can you describe which wiggle room exists? If you use different sized keys
you'll get interop failure, just like if you use different keys of the same
length.

David

On Wed, Aug 14, 2019 at 7:37 AM STARK, BARBARA H <[email-masked]> wrote:

>               defined for the associated babel-mac-key-algorithm, so there
> is no need for the MAC algorithm to zero-pad,
>
> I really dislike SHOULDs and wiggle room in things like this that can
> cause a complete breakdown of interoperability. Hashing is an area where
> it’s very easy to achieve non-interoperability.
>
> Barbara
>
>
>
> *From:* David Schinazi <[email-masked]>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 14 Aug 2019 17:54:56 +0000

Inline with <bhs>. - Barbara

Thanks Barbara!

I meant Babel-MAC implementations.
<bhs> But Juliusz said he wants to remove from babel-hmac all requirements related to what a key is or how long it is. That’s what precipitated this discussion. So this email thread is only considering requirements on (instantiations or implementations of) information-model. But if you can get him to reconsider having something in babel-hmac, that would be great. Maybe come up with a scenario where children would come to actual harm (and not just miss hiking).
Can you describe which wiggle room exists? If you use different sized keys you'll get interop failure, just like if you use different keys of the same length.

<bhs> SHOULD = wiggle room. I know IETF people think SHOULD means you should have a really good reason not to do it. Most implementers just treat SHOULD as optional, though. And “because I didn’t feel like it” tends to be their “really good reason”. I would prefer to constrain key lengths with MUST statements.

David

On Wed, Aug 14, 2019 at 7:37 AM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
I’m unclear – which “implementation” are we talking about? A babel-mac implementation or a data model?

From: David Schinazi <[email-masked]<mailto:[email-masked]>>
@Juliusz: Revised statement, now with 30% more thinking of the children:

If I read Barbara right:

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 14 Aug 2019 19:58:38 +0200

> <bhs> SHOULD = wiggle room. I know IETF people think SHOULD means you should
> have a really good reason not to do it. Most implementers just treat SHOULD as
> optional, though. And “because I didn’t feel like it” tends to be their “really
> good reason”. I would prefer to constrain key lengths with MUST statements.

RFC 6126bis takes the following approach:

  - MUST = not doing it will prevent interoperability;
  - SHOULD = not doing it is a bad idea, but doing it will not prevent
    interoperability.

---

From: David Schinazi <[email-masked]>
Date: Wed, 14 Aug 2019 11:25:11 -0700

I agree with Juliusz's sentiment here. We need to make sure implementations
don't preprocess keys, because that could break interoperability, but other
than that we shouldn't restrict users.

I don't like the inconsistency of allowing something in the Babel+Babel-MAC
specs and not in the information model. As an implementer that would
confuse me.