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

["STARK, BARBARA H" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> 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.

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

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

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 <[e-mail]<mailto:[e-mail]>> 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.

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 <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 15, 2019 6:56 PM
To: STARK, BARBARA H <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Juliusz Chroboczek <[e-mail]<mailto:[e-mail]>>
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 <[e-mail]<mailto:[e-mail]>> wrote:
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

On Thu, Aug 15, 2019 at 9:58 AM STARK, BARBARA H <[e-mail]<mailto:[e-mail]>> wrote:
> > 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.

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

_______________________________________________
babel mailing list
[e-mail]<mailto:[e-mail]>
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=>