Re: FW: Renaming of HKDF-CTR to HKDF

Chrome's HKDF implementation requires the parameter to be specified.

Depending how we update the spec per bug 27425, I can modify Chrome to
match.

Regarding making the salt/info parameters for HKDF optional in the
WebCrypto spec:

  (a) RFC 5869 describes "salt" as being optional (not needing to be
specified), but "info" is described as being "optional" in the sense it can
be 0-length. So if the intent is to exactly match RFC 5869's wording then I
expect we want to leave "info" as a required parameter.

  (b) A 0-length salt in the case of HKDF is the same as an unspecified
salt -- because the HMAC will zero-pads its key up to HashLen. So "omitting
salt" is equivalent to just passing an empty salt using our API AFAICT.

  (c) Not specifying a salt is a poor practice anyway. From the perspective
of our WebCrypto API, having it be optional isn't going to be doing our
users any favors in ease of use, in my opinion. If it is mandatory then
accidentally forgetting it raises an error. And if you really do want to
use the default you can easily pass an empty BufferSource.

  (d) Pbkdf2Params similarly has a "salt" parameter that is currently
required. They are different algorithms, but from the perspective of an API
consumer it feels weird for salt to be mandatory in one but not the other,
when we could just as easily have defined an omitted "salt" to be
equivalent to empty BufferSource for both. From an internal consistency
perspective if we choose to make HKDF's salt optional, we should consider
whether PBKDF2's salt should similarly be optional.

I can appreciate trying to directly match RFC 5869's wording, but my
current inclination would be to leave "salt" as required when adding HKDF's
definition to our spec.

On Tue, Mar 8, 2016 at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> Yes that fixes all of my problems but one.  If the salt is missing, I am
> doing this by not providing the parameter rather than providing a zero
> length array of bytes.  It seems to me to be a reasonable way of doing this
> but is not the same as what the previous IDL did.
>
>
>
> Opinions?
>
>
>
> Jim
>
>
>
>
>
> *From:* Eric Roman [mailto:ericroman@google.com]
> *Sent:* Tuesday, March 08, 2016 2:57 PM
> *To:* Jim Schaad <ietf@augustcellars.com>
> *Cc:* public-webcrypto@w3.org
> *Subject:* Re: FW: Renaming of HKDF-CTR to HKDF
>
>
>
> I haven't run the tests, but looking at your code in:
>
>
> https://github.com/jimsch/web-platform-tests/blob/HKDF/WebCryptoAPI/HKDF_derivebits_known.js
>
>
>
> I believe the problem is simply a typo: "Hash" instead of "hash".
>
>
>
> (The test runner expects "hash", but the SHA1 tests and empty salt/info
> are naming it "Hash").
>
>
>
> On Tue, Mar 8, 2016 at 2:20 PM, Eric Roman <ericroman@google.com> wrote:
>
>
>
>
>
> On Mon, Mar 7, 2016 at 5:56 PM, Jim Schaad <ietf@augustcellars.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Jim Schaad [mailto:ietf@augustcellars.com]
> > Sent: Monday, March 07, 2016 4:46 PM
> > To: 'public-webcrypto@w3.org' <public-webcrypto@w3.org>
> > Subject: RE: Renaming of HKDF-CTR to HKDF
> >
> > For the curious, here is a set of known value tests based on both the
> edits and
> > RFC 5869
> >
> > https://github.com/jimsch/web-platform-tests/tree/HKDF
> >
> > The version of Chrome that I am running does not appear to support
> >       SHA-1
> >       Zero length salt and info
>
>
>
> Can you provide some specific examples of the failures?
>
>
>
> According to Chrome's testing it supports SHA1 and empty salt/info.
>
> For instance these tests exercise those options:
>
>
>
>
> https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/LayoutTests/crypto/subtle/hkdf/deriveBits-rfc5869-test-vectors.html
>
>
>
> >
> > The version of Firefox that I am running fails all of the tests.
> >
> > Jim
>
> >
> > > -----Original Message-----
> > > From: Jim Schaad [mailto:ietf@augustcellars.com]
> > > Sent: Monday, March 07, 2016 3:35 PM
> > > To: public-webcrypto@w3.org
> > > Subject: Renaming of HKDF-CTR to HKDF
> > >
> > > I have done the pull request that I promised on today's conference
> > > call. It can be found at:
> > > https://github.com/w3c/webcrypto/pull/16
> > >
> > > I believe that this correspond to what Rob said that Mozilla has
> implemented.
> > > Please review and comment on the field names.
> > >
> > > Additional issues that can be addressed here:
> > >
> > > 1.  HKDF allows for salt to be optional, there is a bug reported by
> > > Harry
> > > (https://www.w3.org/Bugs/Public/show_bug.cgi?id=27473)  which says
> > > that this may be a problem.  I do not know if this was reported for
> > > the NIST version or for the IETF version of the algorithm.  It may be
> > > that it is just fixed by switching algorithms.  If not then we can
> > > modify the text to provide default salt behavior in the algorithm
> description.
> > >
> > > 2.  I did not address the question of having an export function for
> > > KDF functions
> > > (27774) as it should be done for all of the KDF functions at the same
> time.
> > > However I would support doing this.
> > >
> > > Jim
> > >
> > >
>
>
>
>
>
>