W3C home > Mailing lists > Public > public-webcrypto@w3.org > April 2013

Re: Defaults: Getting concrete (round 2)

From: Richard Barnes <rbarnes@bbn.com>
Date: Thu, 18 Apr 2013 14:14:19 -0400
Cc: Web Cryptography Working Group <public-webcrypto@w3.org>
Message-Id: <0C1E6C9E-4B54-4C02-BA5E-AC215995EEE7@bbn.com>
To: Wan-Teh Chang <wtc@google.com>
Hi Wan-Teh,

Thanks for the feedback.  Responses inline.

On Apr 17, 2013, at 10:25 PM, Wan-Teh Chang <wtc@google.com> wrote:

> Hi Richard,
> 1. I think you have identified the parameters that can have good
> default values. In contrasts, parameters such as RSA key size and the
> hash algorithm used in a signature don't have default values that will
> be good forever.

Thanks!  This proposal is basically me conceding that things like RSA key size are less risky than IVs, and harder to set defaults for.

> 2. I agree with your proposed default values for the 'iv' parameter of
> AES-CBC and AES-CFB. However, if the iv is a random value generated by
> the UA, it must be part of the output of encryption, for example, as
> the first ciphertext block. The spec will need to address this.

This is actually already in the API.  The CryptoOperation object has an "algorithm" field, which is populated with the normalized form of the algorithm used for the operation.  This proposal calls for the random IV generation to be done at normalization, so the "algorithm" field would contain the generated IV.

> 3. As for the 'counter' parameter of AES-CTR and the 'iv' parameter of
> AES-GCM, their proper values are so specific to the protocol or
> application in question that I believe the protocol or application
> will end up fully specify what the proper value for 'counter' or 'iv'
> should be. For example, this is the case for the AES GCM cipher suites
> for TLS (the GCMNonce structure in RFC 5288, Section 3). So it doesn't
> seem as useful for the UA to provide default values for the 'counter'
> parameter of AES-CTR and the 'iv' parameter of AES-GCM.

I agree that there are lots of protocols that have defined ways to shove things into the counter and IV fields for CTR and GCM.  They can always override the default.

I'm more concerned about newer protocols that haven't done something similar (and probably don't need to).  Those protocols just need something that meets the security requirements, and it's easy enough for the UA to provide that.

We've also seen that application designers can also get counter/IV generation badly wrong, as with the recent nonce reuse issue in JOSE:

So while you're right that there are protocols that will not make use of the default, I think that newer things can benefit from having a safe default here.

Received on Thursday, 18 April 2013 18:14:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:16 UTC