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

[David Schinazi <[e-mail]>]

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