Re: Defaults: Getting concrete (round 2)

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:
<http://www.ietf.org/mail-archive/web/jose/current/msg01967.html>

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.

--Richard

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