Re: [babel] info-model: preparing -09 on github
David Schinazi <dschinazi.ietf@gmail.com> Thu, 15 August 2019 23:55 UTC
Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB331200F3 for <babel@ietfa.amsl.com>; Thu, 15 Aug 2019 16:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCMwZOSq1k1B for <babel@ietfa.amsl.com>; Thu, 15 Aug 2019 16:55:12 -0700 (PDT)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044ED1200E9 for <babel@ietf.org>; Thu, 15 Aug 2019 16:55:12 -0700 (PDT)
Received: by mail-lf1-x130.google.com with SMTP id n19so2789894lfe.13 for <babel@ietf.org>; Thu, 15 Aug 2019 16:55:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qYOAf9TZxcpkj3vZZabQVKXuJa7cFHUqdThhxL2SxQo=; b=LtCz70f12juDrzWiv961T3gmfpn1S4RvOYj0xj/4KTRsHTQ+LauqZRnFzl7lJi/XXP rW/a/LUpOGqejNfh+rC69oN4fU+HFr6bheP7l9S9AFuJx4gFybYrveZ82/clNJE1fatb wa6jNtJi04ijgI3ZIxZsMbh1zUG4moKwGz/VTkkzDBp4nuZ+niukAxa4AXhe1eBk5N9A VJHeJ/rO2SKpJWSMVq3O9NcYqBkUzAZ87gODcobmVwZgTesLaaI9visjkcNTMzpBIQ1/ gtRLoOeXlVi+yvkovTmvT27lQFZ0CSSOO+629/5ACxioeEkxvafMRWniB/BBThFp6Ebv YoCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qYOAf9TZxcpkj3vZZabQVKXuJa7cFHUqdThhxL2SxQo=; b=aPPO48DMzD0bOQLpB8ljrTM2rvT5LV+wk93neDgbSogZ5E+42flAz+ajg4JrDVC8Sp IE+YmKmc0M+wS2b5ZiA+dTTftltAFabniL/GKPSRe8YHZnGr7KdB5qZR8l6wtD6D7kt4 VGRgOM9ADHeJK1jNaRgs0rT+9lmAAIXOSMXqbIyq88Uc+faUk4iq9TYMkFyJOXjiR1ZC Omq/mF83pkG/SnxDOHbgtWrwTEB+4hfpCaddto/9Mxcc3DXus0DG0CJblRnwbD7XSyWu sKxIhs0iGRE6FfLjuIQFFKLJdYPtRDAGXfUj4vg8DG5/F7otPeCzqFSSYqCkeg6Nt1jD ttDA==
X-Gm-Message-State: APjAAAXUtVs07+jqL0g2W1l86nvNHOzDzO4Kx2UbIoH6mYI95kYWUFcE 9wP28foOP2Juv93PZTcRDCycRDO9ClMh+yyUpiA=
X-Google-Smtp-Source: APXvYqxDYsoz6fEfiBv1Cy3h3hI7mvurk+yW9Lf9MQOKhVE7HocqzcllRDpa0LVQrtoSZqt1Kuj6Pz10T+S/RtmtYj8=
X-Received: by 2002:a19:428c:: with SMTP id p134mr3370309lfa.166.1565913310211; Thu, 15 Aug 2019 16:55:10 -0700 (PDT)
MIME-Version: 1.0
References: <2D09D61DDFA73D4C884805CC7865E6114E2694DE@GAALPA1MSGUSRBF.ITServices.sbc.com> <87ftm3u0a6.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E269981@GAALPA1MSGUSRBF.ITServices.sbc.com> <87blwrtudx.wl-jch@irif.fr> <2D09D61DDFA73D4C884805CC7865E6114E275E65@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAPDSy+4+46nUbUF=C-U1Jvw2QDZMRZ9-vXrRVwh71y8ne6e0Mg@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E27796E@GAALPA1MSGUSRBF.ITServices.sbc.com> <CAPDSy+79ZOf6fywMmetXn-e+L9LazGaFCO6X=apu7NeDwa9sNw@mail.gmail.com> <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com>
In-Reply-To: <2D09D61DDFA73D4C884805CC7865E6114E277CFA@GAALPA1MSGUSRBF.ITServices.sbc.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 15 Aug 2019 16:54:59 -0700
Message-ID: <CAPDSy+68jJW1um0j3OV-cPk-a2yDYAu5-29Qf0Z7UtV_QmuA9w@mail.gmail.com>
To: "STARK, BARBARA H" <bs7652@att.com>
Cc: "babel@ietf.org" <babel@ietf.org>, Juliusz Chroboczek <jch@irif.fr>
Content-Type: multipart/alternative; boundary="0000000000009ab40e0590309af2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/s-gbFIJyGZvk-fJjfMvFGmCvXqc>
Subject: Re: [babel] info-model: preparing -09 on github
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Aug 2019 23:55:17 -0000
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 <bs7652@att.com> 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/ 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 <dschinazi.ietf@gmail.com> > *Sent:* Thursday, August 15, 2019 6:56 PM > *To:* STARK, BARBARA H <bs7652@att.com> > *Cc:* babel@ietf.org; Juliusz Chroboczek <jch@irif.fr> > *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 <bs7652@att.com> 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 <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 > <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=> > >
- [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github Juliusz Chroboczek
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github Juliusz Chroboczek
- Re: [babel] info-model: preparing -09 on github Mahesh Jethanandani
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github David Schinazi
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github David Schinazi
- Re: [babel] info-model: preparing -09 on github David Schinazi
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github David Schinazi
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github Juliusz Chroboczek
- Re: [babel] info-model: preparing -09 on github Juliusz Chroboczek
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H
- Re: [babel] info-model: preparing -09 on github David Schinazi
- Re: [babel] info-model: preparing -09 on github STARK, BARBARA H