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

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 <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
> https://www.ietf.org/mailman/listinfo/babel
>