[Cfrg] WG last call on latest OCB draft.

OK, it looks like the debate working the tag length into AEAD
encryption has reached either consensus or exhaustion.
Here is where I think we stand:

1) Working the tag length into either the KDF or encryption
   process is a prudent precaution because, at the very least,
   it simplifies the security analysis and guards against
   implementation errors.  Future AEAD modes should STRONGLY 
   consider doing this.

2) OCB is too widespread to make such a substantive change at
   this late date.

3) The changes made in the current OCB draft aren't substantive,
   they merely correct errors in the exposition.

Therefore I want to make a RG last call on draft-irtf-cfrg-ocb-02.
I'll start of the discussion by putting on the floor a motion that 
the RG accept draft-irtf-cfrg-ocb-02 as it stands. Discussion?
Don't be shy. How do the RG and the authors feel about Dan Brown's 
suggestion to insert some text explicitly prohibiting using the same 
key with different OCB lengths?

> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
> Jack Lloyd
> Sent: Tuesday, June 04, 2013 3:01 PM
> To: cfrg@irtf.org
> Subject: Re: [Cfrg] Attacker changing the tag length in OCB
> 
> On Tue, Jun 04, 2013 at 05:49:06PM +0000, Dan Brown wrote:
> 
> > If the intent of the OCB spec is not to allow variable tag lengths,
> then I
> > think the spec needs greater emphasis, especially in view of some
> IETF
> > common practices and viewpoints (**).  So, the spec should somewhere
> say
> [...]
> > (**) For example, TLS allows one public key per multiple different
> cipher
> > suites (not sure if it allows pre-shared key with different cipher
> suites).
> 
> To address TLS-PSK specifically - using a single PSK with several
> different cipher suites is allowed, though as the actual symmetric
> keys are derived from both the PSK and the client and server nonces
> (and, optionally, a DH/ECDH key exchange), the actual OCB key would
> never be reused in a different context, or even in a different session
> with the same parameter set.
> 
> -Jack
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg