Subject: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts

From: "Black, David" <[email-masked]>
Date: Sat, 8 Mar 2014 08:08:37 -0500

> The next draft changes AES-128-CBC to AES-CBC, and says:
> 
> In the following sections, all AES modes are for 128-bit AES. 192-bit AES
> MAY be supported for those modes, but the requirements here are for 128-bit
> AES.

What about 256-bit AES keys?  They should also be a "MAY".

Thanks,
--David

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Saturday, March 08, 2014 6:56 AM
> To: ipsec
> Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts
> 
> On Mar 3, 2014, at 12:02 PM, Valery Smyslov <[email-masked]> wrote:
> 
> > The draft lists the following trasforms based on AES cipher:
> >
> > AES-GCM
> > AES-CCM
> > AES-CTR
> > AES-128-CBC
> > AES-GMAC
> > AES-XCBC-MAC-96
> >
> > All these transforms, except for AES-XCBC-MAC-96,
> > allows to be used with different key lengths - 128, 192 and 256 bits.
> > It looks strange to me that, unlike the others, AES-128-CBC
> > has key length explicitely specified in the draft. Why it differs in
> > this respect from the others? What about AES-192-CBC and
> > AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-)
> >
> > I think the draft should either:
> > - remove explicit key length from AES-128-CBC and make it just AES-CBC
> > - add explicit key length to all other AES-based transforms (except for AES-
> XCBC-MAC-96)
> > - leave things as is, but explain why AES-CBC differs in this respect from
> the others
> 
> The next draft changes AES-128-CBC to AES-CBC, and says:
> 
> In the following sections, all AES modes are for 128-bit AES. 192-bit AES
> MAY be supported for those modes, but the requirements here are for 128-bit
> AES.
> 
> --Paul Hoffman
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Mar 2014 14:10:53 +0000

> What about 256-bit AES keys?  They should also be a "MAY".

Good catch.

--Paul Hoffman

---

From: <[email-masked]>
Date: Sat, 8 Mar 2014 20:00:42 +0000

> What about 256-bit AES keys?  They should also be a "MAY".

Why not “SHOULD” for 192 and 256 bit keys?

	paul

---

From: Yoav Nir <[email-masked]>
Date: Sun, 9 Mar 2014 11:43:38 +0200

With vendor hat on: years ago we measured the performance and found that
the performance of AES-256-CBC and AES-192-CBC were virtually identical. We
removed AES-192-CBC from our UI because we didn't see a point to it - less
security for no performance gain.

I don't have any more recent measurements, but unless there is a good
reason to prefer AES-192-CBC over AES-256-CBC, I'd rather it not be a
SHOULD.

On Sat, Mar 8, 2014 at 10:00 PM, <[email-masked]> wrote:

> Why not "SHOULD" for 192 and 256 bit keys?
>
>         paul
>

---

From: "Black, David" <[email-masked]>
Date: Sun, 9 Mar 2014 22:29:42 -0400

The storage world seems to have done likewise - use 256-bit keys when 128-bits
aren't enough; tape encryption is one source of examples.

Also see Section 7.3 of RFC 5282 (Using Authenticated Encryption Algorithms
with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2)
Protocol) which also recommends 256-bit keys in preference to 192-bit keys.

FWIW, Section 7.2 of the same RFC (which applies to both CCM and GCM) recommends
16-octet ICVs and recommends against 12-octet ICVs.

Thanks,
--David

From: IPsec [mailto:[email-masked]] On Behalf Of Yoav Nir
Sent: Sunday, March 09, 2014 5:44 AM
To: ipsec
Subject: Re: [IPsec] AES key lengths: draft-ietf-ipsecme-esp-ah-reqts

With vendor hat on: years ago we measured the performance and found that the performance of AES-256-CBC and AES-192-CBC were virtually identical. We removed AES-192-CBC from our UI because we didn't see a point to it - less security for no performance gain.
I don't have any more recent measurements, but unless there is a good reason to prefer AES-192-CBC over AES-256-CBC, I'd rather it not be a SHOULD.

On Sat, Mar 8, 2014 at 10:00 PM, <[email-masked]<mailto:[email-masked]>> wrote:

        paul

_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Mar 2014 12:05:22 -0400

Paul
> Why not “SHOULD” for 192 and 256 bit keys?
It's good to remember the reason that 256-bits keys for AES were specified,
i.e., as a hedge against someone building a quantum computer. So, unless the
data being encrypted is expected to have a lifetime far enough into the 
future
as to merit protection against that concern, the extra time needed to 
perform
AES-256 vs. AES-128 does not seem justified.

Steve

---

From: <[email-masked]>
Date: Mon, 10 Mar 2014 16:12:36 +0000

On Mar 10, 2014, at 12:05 PM, Stephen Kent <[email-masked]> wrote:

> data being encrypted is expected to have a lifetime far enough into the future
> as to merit protection against that concern, the extra time needed to perform

That’s a good argument for a user choosing to use AES-128 rather than AES-256.  But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it isn’t used it has no performance impact.

	paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 10 Mar 2014 12:45:28 -0400 (EDT)

> That’s a good argument for a user choosing to use AES-128 rather than AES-256.  But it doesn’t really address why “SHOULD implement” isn’t justified — the implementation cost is trivial and if it i…

It's not the implementation cost that matters. It is the GUI confusion.
For example one vendor uses "aes" as aes128, and another vendor uses
"aes" for aes256 (or aes_ctr or aes_cbc or aes_gcm). Each option we
expose needlessly to the enduser is one more potential interop issue.

Paul

---

From: <[email-masked]>
Date: Mon, 10 Mar 2014 16:58:07 +0000

> expose needlessly to the enduser is one more potential interop issue.

True.  But if you assume sufficiently foolish GUI designs, just about anything can be hard to use.  And I don’t think that good crypto design should be put at the mercy of people who can’t design a decent UI.  We know that it’s possible to get this right.

	paul

---

From: Stephen Kent <[email-masked]>
Date: Mon, 10 Mar 2014 13:29:48 -0400

Paul,
> ...
I have been told by some commercial security consultants that their 
customers believe that
bigger is more secure, and thus they should mandate use of longer key 
lengths if they
are available. If that report is accurate, then making AES-256 a SHOULD 
(vs. a MAY)
creates a situation where the performance penalty will be incurred, for 
no good reason.

But, I'm not going to fall on my sword for this.

Steve

---

From: Gandhar Gokhale <[email-masked]>
Date: Tue, 11 Mar 2014 11:35:45 +0530

And testing cost for one more crypto algorithm when the algorithmic
permutations are already too high!
Gandhar Gokhale
Networking Components Group
LSI

On Mon, Mar 10, 2014 at 10:28 PM,  <[email-masked]> wrote:
>>> That's a good argument for a user choosing to use AES-128 rather than AES-256.  But it doesn't really address why "SHOULD implement" isn't justified -- the implementation cost is trivial and if it isn't used it has no performance impact.
>>
> True.  But if you assume sufficiently foolish GUI designs, just about anything can be hard to use.  And I don't think that good crypto design should be put at the mercy of people who can't design a decent UI.  We know that it's possible to get this right.
>
>         paul
>