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

On Mar 8, 2014 12:29 AM, "Vijay Bharadwaj" <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]
> Sent: Friday, March 7, 2014 11:59 PM
> To: Vijay Bharadwaj
> Cc: Jim Schaad; Mark Watson; 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>
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]
> > Sent: Friday, March 7, 2014 11:32 AM
> > To: Jim Schaad
> > Cc: 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>
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.