Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: Tero Kivinen [mailto:[e-mail]]
> Sent: Monday, August 08, 2016 9:15 AM
> To: Paul Hoffman
> Cc: Yaron Sheffer; [e-mail]; Scott Fluhrer (sfluhrer)
> Subject: Re: [IPsec] I-D Action: draft-fluhrer-qr-ikev2-02.txt
> 
> Paul Hoffman writes:
> > On 5 Aug 2016, at 8:23, Yaron Sheffer wrote:
> >
> > > The trick to that is to add a new column to the IANA table
> > > https://www.iana.org/assignments/ikev2-parameters/ikev2-
> parameters.x
> > > html#ikev2-parameters-5
> >
> > That's the first of two tricks: the second is getting agreement about
> > the rules for the values in that column. It seems like there is still
> > disagreement in the crypto community about how susceptible different
> > algorithms and modes are to quantum.
> 
> As an IANA expert, I am not that happy adding yet another column to that
> table. The ESP/IKEv2 reference columns already seem to make enough
> confusion for people :-)

On the other hand, we need to give people some guidance somehow...

> 
> Also I think it is bad idea to list which ciphers are quantum computing safe, as
> I have no idea whether RC5 or Blowfish are really in that category, even
> when they do have long keys...

There's no known Quantum attack against either (assuming long keys), and so they're in the same category as AES-256.

> 
> It might be better to list ciphers which we consider not to be safe, i.e.,
> explictly note that PRF_AES128_XCBC and PRF_AES128_CMAC are using 128-
> bit keys so they might be vulnerable. (Btw it is PRF_AES128_CMAC, not
> PRF_AES_CBC).

That makes a lot of sense; ultimately, we don't really know which ones are strong against Quantum Computers (then again, we really don't know which ones are strong against conventional computers using undiscovered attacks :-); we do know some are likely weak.

> 
> Also this is something we might want to add to the rfc4307bis provided we
> can agree on the text before it goes forward. I.e. I do not think the
> RFC4307bis should wait for the text, as we can add it the QR document also,
> but if we can agree on that now, then we can add this kind of warning to
> rfc4307bis too. That text could be something like
> this:
> 
>    Quantum computers might able to perform Grover's algorithm; that
>    effectively halves the size of a symmetric key. Because of this, to
>    provide 128-bit security even when we have quantum computers, the
>    symmetric algorithm keys needs to have least 256 bits of entropy.
> 
> Btw, both PRF_AES128_XCBC and PRF_AES128_CMAC do use 128-bit keys
> always, they cannot use longer keys, so the text saying "even though they
> can use larger keys" is wrong, as those versions cannot use longer keys.

Actually, if you look through the definitions of the transforms that IANA points to, RFC4434 and RFC4615, the transform can take as input a "key" longer than 128 bits.  Yes, if you look inside the definition of the transform, you see that they transform the arbitrary-length "key" into a 128 bit one; people quite often don't look into the innards of their crypto (nor should they have to).

> --
> [e-mail]