RE: Comments on RSA-PSS - March 7 Editors Draft

Yes, we’re talking about NCryptSecretAgreement + NCryptDeriveKey.

Ø  If Microsoft does not plan to implement this functionality, it would be an excellent time to register the feedback. Its entirely reasonable to provide that feedback - IndexedDB's sync interfaces, which Israel also mentioned previously, are something in the spec but not widely implemented, so it's not unprecedented.
More precisely, I’m saying that this functionality is not currently possible to implement on top of the OS crypto libraries in existing Windows OS platforms. We had originally expressed this as a goal of WebCrypto (i.e. not to have browsers implement crypto but to give access to the underlying OS crypto for scripts), so this is an issue.

That said, I don’t think that this is really that big of an issue. Maybe it would be good to get feedback from the community on whether anyone cares deeply about running deriveBits with (EC)DH, and that could then be used to determine how to prioritize it.

From: Ryan Sleevi [mailto:sleevi@google.com]
Sent: Saturday, March 8, 2014 3:30 AM
To: Vijay Bharadwaj
Cc: Mark Watson; Jim Schaad; public-webcrypto@w3.org
Subject: RE: Comments on RSA-PSS - March 7 Editors Draft


On Mar 8, 2014 12:29 AM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
>
> CNG doesn’t implement a DH primitive – it implements a DH-based key agreement primitive which is plain DH + a KDF. The default providers don’t currently support DH with a null KDF (which is what you’re asking for) since this is neither safe nor broadly useful in practice. As of Windows 8 we also implement a standalone KDF primitive which as you note allows user-specified keys since this is a known safe and broadly useful piece of functionality.
>

No, not quite a NULL KDF. Use the existing KDF (BCRYPT_HASH_KDF) and set the KDF_HASH_ALGORITHM to an instance of a hash algorithm that noops.

Its still using the built-in KDF of CNG, but exploiting the structure of the KDF to obtain Z - since for the BCRYPT_KDF_HASH, the output is H(hSharedSecret)

This is assuming that NCryptSecretAgreement+NCryptDeriveKey is the correct sequence we're talking about here.

>
>
> It’s possible to implement and install a new CNG provider that supports DH with a null KDF – at some level, it’s all software and software can be extended – but this would not be in the default implementation. The reason is not ideological – it’s just that, as said above, this is neither safe nor useful. So in theory it’s possible that DH deriveBits would be possible when such a provider was installed on the user’s system, the common case would be that only deriveKey would work with most DH keys.
>
>
>
> Let me ask a slightly different but perhaps related question – do you believe that an implementation that always created all its keys with extractable=false (so you could never export private keys from this implementation) would be compliant to the spec?
>

No.

The user - not the implementation - sets the extractability bit.

An implementation that failed to respect the users wish - or, which alternatively raises NotSupportedError every time the user sets extractable=true - would be neither compliant nor terribly useful. It would be implementing something other than what the spec says - or, put it differently, it would be picking and choosing what parts of the spec to implement.

If Microsoft does not plan to implement this functionality, it would be an excellent time to register the feedback. Its entirely reasonable to provide that feedback - IndexedDB's sync interfaces, which Israel also mentioned previously, are something in the spec but not widely implemented, so it's not unprecedented.

We've always acknowledged some *algorithms* may not make the cut. But certainly, fundamentally different API behaviors like that would be... Good to know.

To me, having and impl. do that would be no different than an impl. that failed every other op, or which required the op to be specified exactly the same twice in a row in order to succeed. Its a behavior, certainly, but not one users expect or the spec says, so it would be good to know beforehand.

>
>
> From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
> Sent: Friday, March 7, 2014 11:59 PM
> To: Vijay Bharadwaj
> Cc: Jim Schaad; Mark Watson; public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
> Subject: RE: Comments on RSA-PSS - March 7 Editors Draft
>
>
>
>
> On Mar 7, 2014 9:21 PM, "Vijay Bharadwaj" <Vijay.Bharadwaj@microsoft.com<mailto:Vijay.Bharadwaj@microsoft.com>> wrote:
> >
> > Thanks for bringing this up, Richard.
> >
> >
> >
> > I did point out the same issue in http://lists.w3.org/Archives/Public/public-webcrypto/2014Mar/0019.html - CNG only allows a KDF to be performed on the Z value, and this is more secure (the bits of the secret are not unbiased so should not be used directly). Our implementation would likely just disallow the deriveBits key usage with ECDH and DH, and I believe that would be consistent with the spec today.
> >
>
> That's a spec bug, if so.
>
> An implementation that implements an algorithm MUST implement all the operations - or at least, that should be the requirement. Otherwise you run into situations where you can roach-motel the API and still be conformant - eg: generate a key but never permit any operations with it.
>
> The KDF issue should hardly seem a technical level blocker - you can just use a NoOp hash provider to memoizd Z and spit it back out.
>
> This is fundamentally functionally identical to what CNG is providing developers today via the Alg extension method - a chance to implement any necessary custom KDFs for the appropriate protocols. We're just exposing this to JS - for the exact same reason CNG does: so that we don't have to support/implement every KDF under the sun to be useful to authors.
>
> So is the objection ideological, rather than technical? If so, how does this square with the ability to register custom KDFs that can be fed the secret - something both CAPI and CNG support?
>
> >
> >
> > However, you do bring up a good point – the table of algorithms still says ECDH and DH support deriveKey, but those subsections have vanished from the relevant algorithm specifications.
> >
> >
> >
> > Mark, is this an editorial cut-and-paste mishap, or was it intentional?
> >
> >
> >
> > From: Ryan Sleevi [mailto:sleevi@google.com<mailto:sleevi@google.com>]
> > Sent: Friday, March 7, 2014 11:32 AM
> > To: Jim Schaad
> > Cc: public-webcrypto@w3.org<mailto:public-webcrypto@w3.org>
> > Subject: Re: Comments on RSA-PSS - March 7 Editors Draft
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Mar 7, 2014 at 11:15 AM, Jim Schaad <ietf@augustcellars.com<mailto:ietf@augustcellars.com>> wrote:
> >>
> >> 1.  It should be noted that RFC 4055 from the PKIX group makes the
> >> parameters field optional for id-RSASSA-PSS.  This means that depending on
> >> the standard used, these fields may be absent when importing the key.
> >>
> >> 2.  What happened to the deriveKey descriptions.  I would like to point out
> >> that Microsoft using CNG does not have the ability to get to the secret
> >> value from aa DH key agreement operation.  They will be completely unable to
> >> implement the current specification using their current code.
> >
> >
> >
> > I would prefer that we allow implementors to speak for themselves.
> >
> >
> >
> > While Vijay is correct in stating that Z is not directly exportable, and instead fed to a hash algorithm, one can simply create a new CNG hash provider that no-ops (eg: returns Z when told to H(Z)), to obtain Z.
> >
> >
> >
> > So it's certainly *technically* possible.