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

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 <bs7652@att.com<mailto:bs7652@att.com>> 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
babel@ietf.org<mailto:babel@ietf.org>
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=>