Subject: Re: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 3 Mar 2014 16:02:57 +0400

Hi,

I have mostly no problem with the document.

However I have one small concern.

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

Regards,
Valery Smyslov.

----- Original Message ----- 
From: "Yaron Sheffer" <[email-masked]>
To: "ipsec" <[email-masked]>
Sent: Tuesday, February 25, 2014 10:48 PM
Subject: [IPsec] Working Group Last Call: draft-ietf-ipsecme-esp-ah-reqts

> Hi, this is to start a 2-week working group last call on the revised 
> Algorithm Implementation Requirements document, ending March 11. The draft 
> is at: http://tools.ietf.org/html/draft-ietf-ipsecme-esp-ah-reqts-01. We 
> should have last called the draft a while ago, and I apologize for the 
> delay.
>
> The changes from the existing requirements are listed in Sec. 2.5 of the 
> draft, but most of this (rather short) document is new and describes the 
> rationale for the choice of algorithms and requirement levels.
>
> Please read this draft and send any comments to the WG mailing list, even 
> if the comments are "I see no problems". Comments such as "I do not 
> understand this part" or "this part could be explained better in this way" 
> are particularly useful at this point.
>
> Thanks,
>     Yaron
>
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 3 Mar 2014 17:53:57 +0200

> AES-256-CBC - are they also "MUST" or "MAY"? Or even "MUST NOT"? :-)

Hmm... actually we should most like use the same names we use in the
IANA registry. For example we have 3 different types of AES-GCM:

18   AES-GCM with a 8 octet ICV    [RFC4106]   [RFC5282]
19   AES-GCM with a 12 octet ICV   [RFC4106]   [RFC5282]
20   AES-GCM with a 16 octet ICV   [RFC4106]   [RFC5282]

Which one of those is the one that is moved to SHOULD+? Should we just
pick one of them, and say that it is the one we prefer, or should all
implementations implement all of them? AES-CCM has similar thing, but
as they are moving to MAY it does not really matter.

And yes, I agree the AES-128-CBC should be changed to AES-CBC. In the
RFC4305 and RFC4835 we had text like "AES-CBC with 128-bit keys", but
as we now have more AES modes, we should probably just add text saying
that for 128-bit keys for AES is MUST.

Also for AES-GMAC we need to decide which of the ones we are saying is
SHOULD+:

9	AUTH_AES_128_GMAC	[RFC4543]
10 	AUTH_AES_192_GMAC 	[RFC4543]
11 	AUTH_AES_256_GMAC 	[RFC4543]

> - add explicit key length to all other AES-based transforms (except for 

AES-XCBC-MAC-96 is always defined to be have 128-bit key. The key
length cannot be negotiated when using the authentication algorithm,
it can only be negotiated for the encryption keys. Thats why the
AUTH_AES_*_GMAC authentication algorithms are defined as 3 different
algorithms. 

> - leave things as is, but explain why AES-CBC differs in this respect from 

I think that is bad idea.

I think the best is to say that in general with AES encryption (GCM,
CBC, CCM etc) we assume the key length is 128-bits. (i.e. the
MUST for AES-CBC is for 128-bit keys, and the SHOULD+ for AES-GCM is
also for 128-bit keys with x octect ICV). 
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 3 Mar 2014 17:34:46 -0500 (EST)

> as they are moving to MAY it does not really matter.

Actually yes. I talked to one of the authors of RFC 4106, John Viega,
a while ago and he said:

"Some people seemed  to think embedded devices would want to use truncated
  tags. in this day in age, I would recommend AGAINST tag truncation"

So I would be happy to only move ID 20 to SHOULD+ and actually demote
18 and 19.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Mar 2014 10:10:32 +0400

HI Tero,

> IANA registry.

Agree, this would make things more clear.

> CBC, CCM etc) we assume the key length is 128-bits. (i.e. the

And don't forget about GMAC.

> also for 128-bit keys with x octect ICV).

I also think this is the best way. I listed the other two just for 
completeness.

Valery.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 8 Mar 2014 11:56:03 +0000

On Mar 3, 2014, at 12:02 PM, Valery Smyslov <[email-masked]> wrote:

> - 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 8 Mar 2014 17:42:02 +0400

Hi Paul,

> MAY be supported for those modes, but the requirements here are for 

And please, add the same words for 256-bit AES as for 192-bits AES.

Regards,
Valery.