Re: Defaults: Getting concrete (round 2)

On Fri, Apr 19, 2013 at 3:16 PM, Wan-Teh Chang <wtc@google.com> wrote:
> On Thu, Apr 18, 2013 at 11:14 AM, Richard Barnes <rbarnes@bbn.com> wrote:
>>
>> 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.
>
> 1. Let's first consider the counter field for the CTR mode.
>
> Unless the UA knows about all the CTR mode encryptions that have been
> done with the key in question, the UA cannot generate a new counter
> value that hasn't been used before.
>
> This requires the UA to be the exclusive user of the key in question.
> But if the API allows the key to be exported, the UA won't be the
> exclusive user of the key.

Or a new key imported that has been used previously.

I definitely don't think implementations should be trying to track
what the 'used' counters are - that's certainly the realm and
responsibility of a high-level protocol, and no API does this.

>
> 2. As to the IV field for GCM, I think the UA can use the RBG-based
> construction of the IV in Section 8.2.2 of NIST SP 800-38D. I believe
> this is what you proposed.
>
> 3. This makes me wonder if an RBG-based construction of the counter
> field for the CTR mode would also be acceptable if the probability of
> reusing a counter value is low enough.
>
> Wan-Teh
>

I think the inconsistency argument should be the one we're looking at here.

The argument for having the UA generate the IV is not one being made
on technical requirements, but simply on the basis that "People (may)
use it incorrectly." The fact that the IV needs to be protected
(outside of the AEAD case) should be a compelling reason enough for us
to suggest it's a false argument being presented.

Received on Friday, 19 April 2013 22:47:48 UTC