Subject: [babel] info-model: preparing -09 on github

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

I've got a preview of the upcoming -09 version on my github.
https://github.com/bhstark2/babel-information-model

The README there has links to the current editor's copy at
https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.html

and for a diff between this and -08 at
http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/id/draft-ietf-babel-information-model-08.txt&url2=https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.txt

It should have everything that I agreed to do so far, including the nits I mentioned in request for last call, changes from the 2 initial emails Juliusz sent (what I agreed to change was in my response), and changing hmac to mac in all but a couple of places (the doc reference right now is still to babel-hmac, and "HMAC-SHA256" wasn't changed). I deleted all the issue and change log stuff at the end.

Things I haven't changed but where changes may still happen based on discussion...
1. link properties / metric-comp-algorithm / interface-metric-algorithm / split-horizon: I'm leaning away from any new objects for link property grouping. It may still be useful to provide additional info to help people understand the allowed values.*
2. babel-mac-key-value description to constrain it according to the babel-mac-key-algorithm allowed key length
Barbara

* Proposal was
  babel-metric-comp-algorithms:  List of supported cost computation
      algorithms.  Possible values include "2-out-of-3", and "ETX".
      "2-out-of-3" (a specific case of K-out-of-j ) link sensing is suitable for wired links that are either
       up, in which case they only occasionally drop a packet, or down, in
       which case they drop all packets. "ETX" is a link-quality estimation algorithm that is
       designed to work well with the IEEE 802.11 MAC.

   babel-interface-split-horizon:  Indicates whether or not the split
      horizon optimization is used when calculating metrics on this
      interface.  A value of true indicates split horizon optimization
      is used. Split horizon optimization is useful when running over a
      transitive, symmetric link technology, e.g., a
      point-to-point link or a wired LAN technology such as Ethernet. 
      It is not appropriate for links not known to be symmetric and transitive; in particular,
      split horizon is not appropriate for decentralized wireless link
      technologies (e.g., IEEE 802.11 in ad hoc mode) when routing updates
      are sent over multicast.
---------------------------------------------
Alternate proposal (since above text was copied straight from rfc6126bis)
  babel-metric-comp-algorithms:  List of supported cost computation
      algorithms.  Possible values include "2-out-of-3", and "ETX".
      "2-out-of-3" is a specific case of K-out-of-j described in [rfc6126bis] A.2.1.
      "ETX" is described in [rfc6126bis] A.2.2.

   babel-interface-split-horizon:  Indicates whether or not the split
      horizon optimization is used when calculating metrics on this
      interface.  A value of true indicates split horizon optimization
      is used. Split horizon optimization is described in [rfc6126bis] 3.7.4.

---

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

Thanks, Barbara.

> http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/id/draft-ietf-babel-information-model-08.txt&url2=https://bhstark2.github.io/babel-information-model/draft-ietf-babel-information-model.txt

I didn't see anything wrong.  (Nit: "an implementation attempting to
comply", I suggest "that purports to comply".  It sounds, like, really smart.)

> 1. link properties / metric-comp-algorithm / interface-metric-algorithm
> / split-horizon: I'm leaning away from any new objects for link property
> grouping.

I agree, pending further input.

> 2. babel-mac-key-value description to constrain it according to the
> babel-mac-key-algorithm allowed key length

Here's my current proposal (pending further input):

  This value is of a length suitable for the associated
  babel-mac-key-algorithm.  If algorithm is based on the HMAC
  construction, this value MUST be between 0 and the block size of the
  underlying hash inclusive (64 in the case of HMAC-SHA-256); if it is
  smaller, it is zero-extended before use as specified in Section 2 of RFC
  2104.  If the algorithm is Blake2s, then it MUST be between 0 and 32
  inclusive, and is used as described in Section 3.3 of RFC 7693.

-- Juliusz

---

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

> comply", I suggest "that purports to comply".  It sounds, like, really smart.)

I'll take this under advisement.

> > 1. link properties / metric-comp-algorithm /
> > interface-metric-algorithm / split-horizon: I'm leaning away from any
> > new objects for link property grouping.
> 

I'm not sure what "use" and "used" mean in the context of info-model. Info-model doesn't use these values -- that's babel-hmac's job.
Is this suggesting that it's ok for info-model to provide babel-hmac with any value between 0 and 64 bytes in length for HMAC-SHA256 or between 0 and 32 bytes in length for Blake2s and babel-hmac can be expected to zero-pad? Or are you still expecting info-model to do the zero-padding before providing to babel-hmac?
Barbara

---

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

> Is this suggesting that it's ok for info-model to provide babel-hmac
> with any value between 0 and 64 bytes in length for HMAC-SHA256 or
> between 0 and 32 bytes in length for Blake2s and babel-hmac can be
> expected to zero-pad? Or are you still expecting info-model to do the
> zero-padding before providing to babel-hmac?

The former.  You give me anything between 0 and 32/64, and I deal with it.

-- Juliusz

---

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 14 Aug 2019 13:09:28 -0700

Hi Barabar,

I have one comment on the draft.

Section 3.3 babel-interface-obj has a parameter babel-mac-algorithm, but there is no corresponding explanation for it below. Possibly this might suffice:

babel-mac-algorithm:   The name of the MAC algorithm used on this interface. The value is one of the identities listed as part of babel-mac-algorithms at a global level.

Cheers.

> On Aug 14, 2019, at 8:40 AM, STARK, BARBARA H <[email-masked]> wrote:
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

Mahesh Jethanandani
[email-masked]

---

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

> From: Mahesh Jethanandani <[email-masked]>
> Hi Barabar,
> 
> Section 3.3 babel-interface-obj has a parameter babel-mac-algorithm, but
> there is no corresponding explanation for it below. Possibly this might
> suffice:
> 
> babel-mac-algorithm:   The name of the MAC algorithm used on this
> interface. The value is one of the identities listed as part of babel-mac-
> algorithms at a global level.
> 
> Cheers.

Argh. Thx. That parameter was supposed to have been removed from interfaces (per one of Juliusz' email). Apparently I only removed the description. It went into babel-mac-keys-obj as babel-mac-key-algorithm. I'll delete it from babel-interfaces-obj.
Barbara

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 16:58:19 +0000

> The former.  You give me anything between 0 and 32/64, and I deal with it.

Cool. Then from a purely info-model perspective, it sounds like the key-value parameter length constraints are:

  This value is of a length suitable for the associated
  babel-mac-key-algorithm.  If the algorithm is based on the HMAC
  construction, the length MUST be between 0 and the block size of the
  underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes
  as described in {{RFC4868}}).
  If the algorithm is "BLAKE2s", the length MUST be between 0 and 32 bytes
  inclusive, as described in {{RFC7693}}.

Anything complying with info-model won't supply anything longer than the identified max length.
A babel-hmac implementation may get something as short as zero length, but will be expected to deal with it. Info-model doesn't care and doesn't need to know what "deal with it" means.
For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will zero-pad shorter strings, because that's what the algorithm RFCs say to do (and not because babel-hmac has any extra requirements going beyond the algorithm specs).
Info-model won't send strings longer than the indicated length. If there is a UI to info model that accepts a longer string, hashes it, and then info-model provides the hashed value, that is what it is. Neither info-model nor babel-hmac care or know or need to know about this.
If a babel-hmac implementation does have special handling for longer strings, that's fine, too. But a value coming from info-model will never trigger this special code.
Does that sound right?
Barbara

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Aug 2019 12:26:26 -0700

According to RFC 7693, Blake2s keys must be of length kk where 0 <= kk <=
32. So having the info model dictate that keys MUST follow that is
perfectly reasonable to me.

However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk
where 0 <= kk. I don't think the information model should express an
opinion as to whether keys longer than 64 bytes are safe or not. If we
choose to add that distinction we'll need to justify why we think the key
hashing is unsafe, and I don't think there is an RFC we can cite for that.

So going back to Juliusz's listed options in the other thread <
https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y>, I
would argue for option 3 "bureaucratic" because it follows the design
principle "The Babel WG does not make security decisions, we follow what
RFCs tell us".

David

On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H <[email-masked]> wrote:

> Cool. Then from a purely info-model perspective, it sounds like the
> key-value parameter length constraints are:
>
> A babel-hmac implementation may get something as short as zero length, but
> will be expected to deal with it. Info-model doesn't care and doesn't need
> to know what "deal with it" means.
> For HMAC and Blake2s algorithms, "deal with it" means hmac-babel will
> zero-pad shorter strings, because that's what the algorithm RFCs say to do
> (and not because babel-hmac has any extra requirements going beyond the
> algorithm specs).
> Info-model won't send strings longer than the indicated length. If there
> is a UI to info model that accepts a longer string, hashes it, and then
> info-model provides the hashed value, that is what it is. Neither
> info-model nor babel-hmac care or know or need to know about this.
> If a babel-hmac implementation does have special handling for longer
> strings, that's fine, too. But a value coming from info-model will never
> trigger this special code.
> Does that sound right?
> Barbara
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 21:46:01 +0000

I disagree.

The HMAC specs (RFC2104) says:
   Applications that use keys longer
   than B [block size] bytes will first hash the key using H and then use the
   resultant L [hash output size] byte string as the actual key to HMAC. In any case the
   minimal recommended length for K is L bytes (as the hash output
   length). See section 3 for more information on keys.
and from section 3

   The key for HMAC can be of any length (keys longer than B bytes are

   first hashed using H).  However, less than L bytes is strongly

   discouraged as it would decrease the security strength of the

   function.  Keys longer than L bytes are acceptable but the extra

   length would not significantly increase the function strength. (A

   longer key may be advisable if the randomness of the key is

   considered weak.)

In this language, there is no requirement for applications using HMAC to accept (or be able to use) keys longer than B bytes. The two statements do say what must happen *if* a key longer than B bytes is provided. But if Babel wants to restrict keys to no more than B bytes, that is well within Babel’s purview to do so. RFC2106 very clearly tells applications get to decide what to use.

The other thing I get from this, though, is that it’s recommended to have at least L bytes for an HMAC key (L = 32 for SHA-256). I think we should reflect this recommendation. We could do it either with a “SHOULD” or “MUST” be at least the output hash length (not set the minimum at 0). I see no reason not to upgrade that to a MUST for Babel, if we want. [It’s always ok to be stricter than a referenced spec (e.g., change SHOULD to MUST) – it’s just not ok to do or allow something that violates a requirement from the spec (e.g., change MUST to SHOULD).] I think at least a MUST be at least 8 bytes” with a “SHOULD be at least the output hash length” would be good for HMAC. It’s also ok for the information model to be stricter than the babel-hmac implementation.

Blake2s does specifically allow zero-length keys – though I don’t know how advisable that is in a Babel usage scenario. I don’t know when key length of 0 is useful. But there is definitely nothing that prevents us from being stricter, if we wanted to insist on a key longer than 0. Again, this strictness can be in info-model only and doesn’t have to be reflected in babel-hmac.

I do need some maximum size on the parameter (independent of key algorithm) – so it won’t be unlimited length, anyway. I’m thinking 128 bytes as an absolute upper limit at this time.
Barbara

According to RFC 7693, Blake2s keys must be of length kk where 0 <= kk <= 32. So having the info model dictate that keys MUST follow that is perfectly reasonable to me.

However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk where 0 <= kk. I don't think the information model should express an opinion as to whether keys longer than 64 bytes are safe or not. If we choose to add that distinction we'll need to justify why we think the key hashing is unsafe, and I don't think there is an RFC we can cite for that.

So going back to Juliusz's listed options in the other thread <https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_babel_QlvsPB9yYFPTPwQxaLcWIN3Hl2Y&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=r4dKW0HNSrjNPXdXIdJ_3kGc3XrRIxdBac60Dua9F9Q&s=hcwi5QDwG7wq96cE5vUbJ6LYJ0mNn6p0iGstPoskzO8&e=>>, I would argue for option 3 "bureaucratic" because it follows the design principle "The Babel WG does not make security decisions, we follow what RFCs tell us".

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=r4dKW0HNSrjNPXdXIdJ_3kGc3XrRIxdBac60Dua9F9Q&s=5hUNj6-VdzK_NqcP_jOOoRJuQ_W388v5YT6Zl2RqxDg&e=>

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Aug 2019 15:56:27 -0700

If we're considering adding restrictions specific to Babel (and/or the info
model), I think we should take a principled approach. What fundamental
principles are we using to decide these restrictions? If we allow a 1-byte
key but disallow a 65-byte key, then the principle we're after is not
improving security?

On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H <[email-masked]> wrote:

> In this language, there is no requirement for applications using HMAC to
> accept (or be able to use) keys longer than B bytes. The two statements do
> say what must happen **if** a key longer than B bytes is provided. But if
> Babel wants to restrict keys to no more than B bytes, that is well within
> Babel’s purview to do so. RFC2106 very clearly tells applications get to
> decide what to use.
>
>
>
> The other thing I get from this, though, is that it’s recommended to have
> at least L bytes for an HMAC key (L = 32 for SHA-256). I think we should
> reflect this recommendation. We could do it either with a “SHOULD” or
> “MUST” be at least the output hash length (not set the minimum at 0). I see
> no reason not to upgrade that to a MUST for Babel, if we want. [It’s always
> ok to be stricter than a referenced spec (e.g., change SHOULD to MUST) –
> it’s just not ok to do or allow something that violates a requirement from
> the spec (e.g., change MUST to SHOULD).] I think at least a MUST be at
> least 8 bytes” with a “SHOULD be at least the output hash length” would be
> good for HMAC. It’s also ok for the information model to be stricter than
> the babel-hmac implementation.
>
>
>
> Blake2s does specifically allow zero-length keys – though I don’t know how
> advisable that is in a Babel usage scenario. I don’t know when key length
> of 0 is useful. But there is definitely nothing that prevents us from being
> stricter, if we wanted to insist on a key longer than 0. Again, this
> strictness can be in info-model only and doesn’t have to be reflected in
> babel-hmac.
>
>
>
> I do need some maximum size on the parameter (independent of key
> algorithm) – so it won’t be unlimited length, anyway. I’m thinking 128
> bytes as an absolute upper limit at this time.
>
> Barbara
>
>
>
> https://mailarchive.ietf.org/arch/msg/babel/QlvsPB9yYFPTPwQxaLcWIN3Hl2Y
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_babel_QlvsPB9yYFPTPwQxaLcWIN3Hl2Y&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=r4dKW0HNSrjNPXdXIdJ_3kGc3XrRIxdBac60Dua9F9Q&s=hcwi5QDwG7wq96cE5vUbJ6LYJ0mNn6p0iGstPoskzO8&e=>>,
> I would argue for option 3 "bureaucratic" because it follows the design
> <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=r4dKW0HNSrjNPXdXIdJ_3kGc3XrRIxdBac60Dua9F9Q&s=5hUNj6-VdzK_NqcP_jOOoRJuQ_W388v5YT6Zl2RqxDg&e=>
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 15 Aug 2019 23:39:59 +0000

As RFC2104 says: “Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength.” Since 64 = 2*L for SHA-256, a key longer than 64 is even less likely to increase the function strength. So key length > 64 provides no added value. But it does increase complexity for creating the “real” key. Increased complexity means more things can go wrong.

I don’t think we should allow a 1-byte key. My recommendation for SHA-256 was MUST be > 8. I found this site: https://www.keylength.com/en/4/ which says NIST recommends minimum of 16 bytes for SHA-256 keys. I’m good with requiring that, too. It would certainly make us current on best practice security recommendations. There’s something to be said for following best practices.

I have no idea what to do for Blake2s. I can’t find a minimum key length recommendation. But zero-length (unkeyed) usage provides no meaningful security in the Babel use case. Zero-length is probably the first thing an attacker would try. And they’d be immediately right. That hardly counts as a brute force attack. So I’m not comfortable with allowing zero-length in info-model.

And just to be clear, I’m not suggesting any of these restrictions go in babel-hmac. Just info-model.
Barbara

From: David Schinazi <[email-masked]>
Sent: Thursday, August 15, 2019 6:56 PM
To: STARK, BARBARA H <[email-masked]>
Cc: [email-masked]; Juliusz Chroboczek <[email-masked]>
Subject: Re: [babel] info-model: preparing -09 on github

If we're considering adding restrictions specific to Babel (and/or the info model), I think we should take a principled approach. What fundamental principles are we using to decide these restrictions? If we allow a 1-byte key but disallow a 65-byte key, then the principle we're after is not improving security?

On Thu, Aug 15, 2019 at 2:46 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
I disagree.

   considered weak.)

David

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Aug 2019 16:54:59 -0700

Why add restrictions to the info model and not to babel-hmac? If we believe
something is insecure shouldn't we ban it even when the info model isn't
being used?

On Thu, Aug 15, 2019 at 4:40 PM STARK, BARBARA H <[email-masked]> wrote:

> As RFC2104 says: “Keys longer than L bytes are acceptable but the extra
> length would not significantly increase the function strength.” Since 64 =
> 2*L for SHA-256, a key longer than 64 is even less likely to increase the
> function strength. So key length > 64 provides no added value. But it does
> increase complexity for creating the “real” key. Increased complexity means
> more things can go wrong.
>
>
>
> I don’t think we should allow a 1-byte key. My recommendation for SHA-256
> was MUST be > 8. I found this site: https://www.keylength.com/en/4/ which
> says NIST recommends minimum of 16 bytes for SHA-256 keys. I’m good with
> requiring that, too. It would certainly make us current on best practice
> security recommendations. There’s something to be said for following best
> practices.
>
>
>
> I have no idea what to do for Blake2s. I can’t find a minimum key length
> recommendation. But zero-length (unkeyed) usage provides no meaningful
> security in the Babel use case. Zero-length is probably the first thing an
> attacker would try. And they’d be immediately right. That hardly counts as
> a brute force attack. So I’m not comfortable with allowing zero-length in
> info-model.
>
>
>
> *From:* David Schinazi <[email-masked]>
> *Sent:* Thursday, August 15, 2019 6:56 PM
> *To:* STARK, BARBARA H <[email-masked]>
> *Cc:* [email-masked]; Juliusz Chroboczek <[email-masked]>
> *Subject:* Re: [babel] info-model: preparing -09 on github
>
>
>
> If we're considering adding restrictions specific to Babel (and/or the
> info model), I think we should take a principled approach. What fundamental

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Aug 2019 00:03:53 +0000

"Be liberal in what you accept, and conservative in what you send"
To be robust, info-model needs to be conservative in what it sends to a babel-hmac implementation. And babel-hmac needs to be liberal in what it accepts.

But if you can get Juliusz to agree to restrictions in babel-hmac, and all the reviewers (because it’s a significant change), I’m fine with that. I do think it’s dangerous at this point in the review process (unless there were comments that could be resolved by such restrictions?). OTOH, it might make reviewers happier to see such restrictions.
Barbara

Sent: Thursday, August 15, 2019 7:55 PM

Why add restrictions to the info model and not to babel-hmac? If we believe something is insecure shouldn't we ban it even when the info model isn't being used?

On Thu, Aug 15, 2019 at 4:40 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
As RFC2104 says: “Keys longer than L bytes are acceptable but the extra length would not significantly increase the function strength.” Since 64 = 2*L for SHA-256, a key longer than 64 is even less likely to increase the function strength. So key length > 64 provides no added value. But it does increase complexity for creating the “real” key. Increased complexity means more things can go wrong.

I don’t think we should allow a 1-byte key. My recommendation for SHA-256 was MUST be > 8. I found this site: https://www.keylength.com/en/4/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keylength.com_en_4_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=CVnWUWmXiv2eGlUvIDrsbxqvnkQ0CJetZJ3ozz9SIjs&s=ezzvxzZqyi23kzEvBdhVuL2SfnjKMsa7Wcve8ysZbas&e=> which says NIST recommends minimum of 16 bytes for SHA-256 keys. I’m good with requiring that, too. It would certainly make us current on best practice security recommendations. There’s something to be said for following best practices.

From: David Schinazi <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 15, 2019 6:56 PM
To: STARK, BARBARA H <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; Juliusz Chroboczek <[email-masked]<mailto:[email-masked]>>
Subject: Re: [babel] info-model: preparing -09 on github

   considered weak.)

David

---

From: David Schinazi <[email-masked]>
Date: Thu, 15 Aug 2019 17:56:34 -0700

Postel's Law isn't something we should be following in this day and age
(further reading: <
https://tools.ietf.org/html/draft-iab-protocol-maintenance-03>).

I worry that if you add restrictions at the info model layer, the UI layer
will preprocess the keys outside of all standards and that could lead to
interoperability issues.

On Thu, Aug 15, 2019 at 5:04 PM STARK, BARBARA H <[email-masked]> wrote:

> To be robust, info-model needs to be conservative in what it sends to a
> babel-hmac implementation. And babel-hmac needs to be liberal in what it
> accepts.
>
>
>
> But if you can get Juliusz to agree to restrictions in babel-hmac, and all
> the reviewers (because it’s a significant change), I’m fine with that. I do
> think it’s dangerous at this point in the review process (unless there were
> comments that could be resolved by such restrictions?). OTOH, it might make
> reviewers happier to see such restrictions.
>
> Barbara
>
>
>
> *Sent:* Thursday, August 15, 2019 7:55 PM
> Why add restrictions to the info model and not to babel-hmac? If we
> believe something is insecure shouldn't we ban it even when the info model
> isn't being used?
>
>
>
> was MUST be > 8. I found this site: https://www.keylength.com/en/4/
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.keylength.com_en_4_&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=CVnWUWmXiv2eGlUvIDrsbxqvnkQ0CJetZJ3ozz9SIjs&s=ezzvxzZqyi23kzEvBdhVuL2SfnjKMsa7Wcve8ysZbas&e=>
> which says NIST recommends minimum of 16 bytes for SHA-256 keys. I’m good
> with requiring that, too. It would certainly make us current on best
> practice security recommendations. There’s something to be said for
> following best practices.
>
>
>

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Aug 2019 14:33:10 +0000

Thinking on this overnight...
I think minimum key lengths are needed.

  *   If info-model min >= babel-hmac min (which includes the case where babel-hmac min is zero), there is no pre-processing that happens at the UI / info-model layer as a result. Entering the same value directly to babel-hmac that is allowed and provided via info-model will produce the same results.
  *   If info-model min < babel-hmac min (which includes the case where babel-hmac sets a min but info-model doesn’t), then we’ll get errors from short values sent via info-model. This is undesirable. Upstream restrictions always need to be greater than or equal to downstream minimum restrictions.

Therefore, I would like to have minimums specified in info-model. If we have them in babel-hmac, that’s ok, but then I need to make sure info-model mins >= babel-hmac mins; but if babel-hmac has no minimums, it won’t cause problems.

We also need to say something about upper limits. I understand what you’re saying about not wanting pre-processing at the UI that may or may not follow standards. I think that’s reasonable. I can include UI advice to explain this would be a bad idea. Info-model can’t normatively require a front-ending UI to do or not do something, but advice is ok.
Blakes2s defines no mechanism for processing keys longer than 32. This is a hard limit per the RFC. I would expect a babel-hmac implementation to enforce this limit, implicitly (because RFC7693 says so). I need to enforce it in info-model, too, or expect errors.
For HMAC, keys longer than the block size don’t add value/security. So if info-model restricts size, but also states that any UI feeding it is expected likewise to restrict size, then there will be no preprocessing in the sense of hashing longer strings. If babel-hmac allows longer keys (and hashes them) there’s no problem. A user wanting to use either a UI front-ending an info-model or enter something directly into babel-hmac will simply understand they can’t use something longer (which users don’t tend to have a problem with).

But if we are consciously considering a user might enter keys directly to babel-hmac or via a UI front-ending an info-model, then info-model also needs to provide advice about the ASCII vs. UTF-n input string interpretation. This was an item of discussion in January. If the info-model UI and babel-hmac UI interpret user input differently, there will be a problem.

So...
You and Juliusz need to figure out what or whether you want babel-hmac to impose restrictions. For info-model, my new latest suggestion is:

  This value is of a length suitable for the associated
  babel-mac-key-algorithm. The length SHOULD meet minimum length
  recommendations for achieving reasonable protection against brute force
  attacks. If the algorithm is based on the HMAC
  construction, the length SHOULD be greater than or equal to 16 bytes and SHOULD
 be less than or equal to the block size of the
  underlying hash (where "HMAC-SHA256" block size is 64 bytes
  as described in {{RFC4868}}).
  If the algorithm is "BLAKE2s", the length MUST be less than or equal to
 32 bytes, as described in {{RFC7693}}, and SHOULD be greater than
 or equal to 16 bytes.
  If values are provided through strings input to a user interface (UI), It is expected
  these input strings will be converted to ASCII values or allow the user
  to explicitly identify the conversion to use (with ASCII being an option).
  A UI is expected to impose any implemented length restrictions, so no
 additional processing is done to user input to make it longer or shorter.

Barbara

Postel's Law isn't something we should be following in this day and age (further reading: <https://tools.ietf.org/html/draft-iab-protocol-maintenance-03<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Diab-2Dprotocol-2Dmaintenance-2D03&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=6P4oaZAW_LJ_4hVz9hdClWoNcztneICGhTY_shYkFUo&s=yz0CHQ1OrRzImhkkUlDteEsnKbpnG5APOHrVcLJ-QjY&e=>>).

I worry that if you add restrictions at the info model layer, the UI layer will preprocess the keys outside of all standards and that could lead to interoperability issues.

On Thu, Aug 15, 2019 at 5:04 PM STARK, BARBARA H <[email-masked]<mailto:[email-masked]>> wrote:
"Be liberal in what you accept, and conservative in what you send"
To be robust, info-model needs to be conservative in what it sends to a babel-hmac implementation. And babel-hmac needs to be liberal in what it accepts.

   considered weak.)

David

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 16 Aug 2019 17:02:51 +0200

Barbara suggested:

> underlying hash inclusive (where "HMAC-SHA256" block size is 64 bytes as
> described in {{RFC4868}}).  If the algorithm is "BLAKE2s", the length
> MUST be between 0 and 32 bytes inclusive, as described in {{RFC7693}}.

I fully support this formulation.

David commented:

> However, according to RFC 6234, HMAC-SHA-256 allows all key lengths kk where 0
> <= kk. I don't think the information model should express an opinion as to
> whether keys longer than 64 bytes are safe or not.

What is suggested by 6234 is to hash longer keys.  By doing that, we'd be
implying that Babel-HMAC is suitable for use with a human-entered
keyphrase.  Since Babel-HMAC is trivially vulnerable to brute-force
attacks, this is not a good idea.  (I'll add a few words on this subject
to the security considerations of Babel-MAC.)

Ideally, Babel-HMAC should be used with a randomly drawn key.  In this
case, the person drawing the key can draw a key of arbitrary length, and
32 bytes is a good choice for both algorithms.  (Using a key larger than
the hash size, while technically possible, does not increase security to
my knowledge.)

If use of a passphrase is desired, then the key should be derived using
a KDF that makes brute-force attacks difficult, such as PBKDF2 or bcrypt.
In that case, the original passphrase should be kept on a secure host
(e.g. the network administator's carefully secured laptop), and only the
resulting key be communicated through the management interface.  Since key
derivation functions are parametrisable in the size of the output key, the
hashing procedure described for HMAC is not used.

Finally, our goal is to get these protocols deployed by real people; thus,
we should not forbid the use of short keys for testing.  A UI should
perhaps display a warning for a key with low entropy (either a short key
or a key that contains multiple repeated strings, e.g. 123412341234...),
but it should not prevent if from being used.

In conclusion, Barbara's formulation above suits me.  If you wish to
change it, please preserve the two following properties:

  - make it clear that it's a key, not a passphrase;
  - allow short keys.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 16 Aug 2019 17:08:18 +0200

> I don’t know how advisable that is in a Babel usage scenario.

For testing.

A 0-length key is a good way to signal the fact that this key is for
testing and should not be used in production.  Using the key 74657374
(which is the ASCII representation of the string "test") makes the message
less obvious.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Aug 2019 19:42:35 +0000

> > as described in {{RFC4868}}).  If the algorithm is "BLAKE2s", the
> > length MUST be between 0 and 32 bytes inclusive, as described in
> {{RFC7693}}.
> 

I'm happy to go with this. I'm putting it in my editor's copy.
Barbara

---

From: David Schinazi <[email-masked]>
Date: Fri, 16 Aug 2019 13:26:47 -0700

I'm getting a sense that I'm in the rough here. I don't feel too strongly
about this issue, and I can live with this choice even though it's not my
favorite. Thanks for letting me say my piece, and considering it as an
option.

David

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 16 Aug 2019 20:55:29 +0000

I think it may be useful to put some additional text in the info-model security considerations (similar to what Juliusz suggests for babel-hmac).
Following are some of the points:

  *   Explain that using ASCII from user-input text as a MAC key for production systems isn’t recommended.
  *   Length of keys for HMAC algorithms is restricted to the block size for the algorithm, because the algorithm will simply hash a longer key down to the block size.
  *   Zero length keys are a really bad idea for a production system, but are supported for testing purposes.
  *   Current recommended best practices from NIST are to use length of at least 16 bytes for SHA-256. It’s a good idea to identify and use best practice recommendations for key length and complexity.
  *   Read babel-hmac and specifications defining MAC algorithm for additional security advice around keys.
  *   Read babel-dtls and DTLS specifications for additional security advice in using DTLS.

Barbara

From: babel <[email-masked]> On Behalf Of David Schinazi
Sent: Friday, August 16, 2019 4:27 PM
To: STARK, BARBARA H <[email-masked]>
Cc: [email-masked]; Juliusz Chroboczek <[email-masked]>
Subject: Re: [babel] info-model: preparing -09 on github

I'm getting a sense that I'm in the rough here. I don't feel too strongly about this issue, and I can live with this choice even though it's not my favorite. Thanks for letting me say my piece, and considering it as an option.

David