Re: [MLS] Substitute AES-128-GCM with AES-256-GCM for TreeKEM

Currently the specification seems to require the application layer
messages are protected by the same AEAD defined in the handshake. [1] Do
you intend for the nonces to be deterministically generated for
application messages as well? If so, there is a risk state handling
bugs which SIV would mitigate. 

Alternatively, if the message layer is going to use a misuse resistant
algorithm, we might as well use it in the handshake as well? 

[1] Based on
https://github.com/mlswg/mls-protocol/blob/master/draft-ietf-mls-protocol.md
which differs from the current IETF draft. 

On Wed, 19 Sep 2018 13:37:13 -0500
Richard Barnes <rlb@ipv.sx> wrote:

> In this case, I think we can do better than SIV by requiring that
> nonces be generated in a certain way.  When I added TreeKEM, I erred
> in having an independent nonce field in the ECIESCiphertext struct.
> Instead, we should generate the nonce from the ECDH exchange, in
> parallel with the key, precisely as TLS does.
> 
> On Wed, Sep 19, 2018 at 1:31 PM Dennis Jackson
> <dennis.jackson@cs.ox.ac.uk> wrote:
> 
> > Would it be reasonable to apply a misuse resistant scheme such as
> > AES-GCM-SIV? [1].
> >
> > I am more concerned by implementations getting nonce generation
> > wrong than the delta between 128 / 256 keys.
> >
> > [1] https://eprint.iacr.org/2017/168.pdf
> >
> > On Wed, 19 Sep 2018 13:14:48 -0500
> > Richard Barnes <rlb@ipv.sx> wrote:
> >  
> > > The obvious argument against this is that you don't ultimately
> > > get the benefit of the bigger key.  Since you're generating the
> > > key off of a P-256 operation, your security level to limited to
> > > 128 bits.  The only way that argument wouldn't hold is if you
> > > thought for some reason that AES-128-GCM was going to degrade
> > > faster than P-256, or if you wanted to argue that AES-128-GCM
> > > isn't really providing a 128-bit security level.
> > >
> > > You could, of course, have a cipher suite where you upgrade
> > > everything: AES-256-GCM, P-521, SHA-512.  But in that case, the
> > > size of a message basically doubles.  Concretely: an element in a
> > > TreeKEM path has (1) a public key for the node (2) an encrypted
> > > node secret with is (2a) a public key (2b) an encrypted hash
> > > output and (2c) a GCM tag.  With the *256 suite, that comes to
> > > 178 = 65 + (65 + 32 + 16) and with the *512 suite, 346 = 133
> > > + (133 + 64 + 16).
> > >
> > > If other folks are keen on AES-256-GCM, I don't think there's any
> > > major harm in upgrading the P-256-based scheme to use AES-256-GCM,
> > > but I don't think there's much benefit either.  Likewise, if folks
> > > want to add a higher-security-level suite, I wouldn't be opposed,
> > > but I don't think it'll get much use.  In the Firefox TLS
> > > telemetry [1], the AES-256-GCM ciphersuites get more than 6x the
> > > use that the AES-128-GCM suites do.
> > >
> > > --Richard
> > >
> > > [1] https://mzl.la/2PPT1YL
> > > 1 = RSA + AES-128-GCM = 55%
> > > 2 = ECDSA + AES-128-GCM = 18%
> > > 13 = ECDSA + AES-256-GCM =1%
> > > 14 = RSA + AES-256-GCM = 10%
> > >
> > > On Wed, Sep 19, 2018 at 12:17 PM Raphael Robert <raphael@wire.com>
> > > wrote:
> > >  
> > > > I am proposing to substitute AES-128-GCM with AES-256-GCM for
> > > > TreeKEM:
> > > >
> > > > https://github.com/mlswg/mls-protocol/pull/60
> > > >
> > > > There was no particular reason why AES-128-GCM was chosen
> > > > initially, and there is no obvious security downside to
> > > > AES-256-GCM.
> > > >
> > > > Raphael
> > > > _______________________________________________
> > > > MLS mailing list
> > > > MLS@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/mls
> > > >  
> >
> >
> >
> > --
> > PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC
> >
> > _______________________________________________
> > MLS mailing list
> > MLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/mls
> >  

-- 
PGP Fingerprint: 5B93 F0B9 D6A8 9BC1 546B C98C 6105 A775 8CD2 46AC