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

[David Schinazi <[e-mail]>]

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]> 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]> 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]
> 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=>
>
>