Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms

From: Russ Housley <[email-masked]>
Date: Mon, 1 Aug 2016 13:03:49 -0400

Jim:

In my view, AES-192 should not be included in the MUST or SHOULD statements.  We should be silent about it, which means that it MAY be implemented.

Further, I think that AES-128 CBC MUST be implemented, to provide a point of transition for 3.1 to 3.5.

Russ

On Aug 1, 2016, at 1:05 AM, Jim Schaad <[email-masked]> wrote:

> I am not back onto a normal daylight schedule and have gotten through a
> couple of other documents so I am ready to start dealing with issues in the
> S/MIME documents.  So this is the first of a series of open issue messages
> that I will start dribbling out as things seem to come to a conclusion.
> 
> This message looks at Content Encryption Algorithms.  Please restrict your
> discussions to this set of algorithms, I will be sending out messages on
> other algorithm times over time.
> 
> Current Document for S/MIME 3.1
> 
> MUST: AES-128 CBC
> SHOULD+: AES-192 CBC and AES-256 CBC
> SHOULD-: DES EDE3 CBC (tripleDES)
> Historic: RC2/40
> 
> Proposed for S/MIME 3.5
> 
> MUST:  AES-192 CBC, AES-256 CBC, AES-256 GCM
> SHOULD+: ChaCha20/Poly1305 (256-bit)
> SHOULD-: AES-128 CBC
> Historic: RC2/40, DES EDE3 CBC (tripleDES)
> 
> Questions:
> 1.  The jump from MUST to SHOULD- may be too aggressive for AES-128 CBC, we
> should potentially state this as MUST- but I think being aggressive makes
> more sense as we want to go to all AEAD algorithms in next version.
> 
> 2.  No recommendation for: AES-128 GCM or AES-192 GCM, should there be?  How
> do people feel about 128 and 192 bit algorithms?
> 
> 3.  Do we want to downgrade all of the CBC algorithms in favor of GCM
> algorithms?
> 
> Jim
> 
> 
> 
> 
> _______________________________________________
> Spasm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/spasm

---

From: Michael Richardson <[email-masked]>
Date: Mon, 01 Aug 2016 13:41:26 -0400

why do you say that AES192 is not an interesting algorithm in the progress towards support of stronger algs? not worth the step,  market confusion... 

On 1 August 2016 13:03:49 GMT-04:00, Russ Housley <[email-masked]> wrote:
>Jim:
>
>In my view, AES-192 should not be included in the MUST or SHOULD
>statements.  We should be silent about it, which means that it MAY be
>implemented.
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 1 Aug 2016 10:55:34 -0700

Would MUST- be reasonable for AES-128 CBC?

jim

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Monday, August 01, 2016 10:04 AM
> To: Jim Schaad <[email-masked]>
> Cc: SPASM <[email-masked]>
> Subject: Re: [Spasm] Change of Algorithms: Content Encryption Algorithms
> 
> Jim:
> 
statements.
> We should be silent about it, which means that it MAY be implemented.
> 
> Further, I think that AES-128 CBC MUST be implemented, to provide a point
of
> transition for 3.1 to 3.5.
> 
> Russ
> 
> 
> > I am not back onto a normal daylight schedule and have gotten through
> > a couple of other documents so I am ready to start dealing with issues
> > in the S/MIME documents.  So this is the first of a series of open
> > issue messages that I will start dribbling out as things seem to come to
a
> conclusion.
> >
> > This message looks at Content Encryption Algorithms.  Please restrict
> > your discussions to this set of algorithms, I will be sending out
> > messages on other algorithm times over time.
> >
> > 1.  The jump from MUST to SHOULD- may be too aggressive for AES-128
> > CBC, we should potentially state this as MUST- but I think being
> > aggressive makes more sense as we want to go to all AEAD algorithms in
next
> version.
> >
> > 2.  No recommendation for: AES-128 GCM or AES-192 GCM, should there
> > be?  How do people feel about 128 and 192 bit algorithms?
> >

---

From: Blake Ramsdell <[email-masked]>
Date: Mon, 1 Aug 2016 11:21:08 -0700

I am going to ask this for every MUST that has multiple options for
every algorithm type, so you might consider pre-emptively having a
statement for why there are multiple options.

> MUST:  AES-192 CBC, AES-256 CBC, AES-256 GCM

Why are there three MUST algorithms?

I'll further elaborate that I think there should be one for
compatibility with that old algorithm that we used to use, one for teh
new hotness algorithm that we're going to use now, and one SHOULD or
SHOULD+ for the "on deck" algorithm.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 1 Aug 2016 18:36:23 +0000

> why do you say that AES192 is not an interesting algorithm in the progress towards support of stronger algs? not worth the step, market confusion... 

I agree with Russ that AES192 is not interesting.  Not to speak for Russ, but my reasons include what you listed above and also that times have changed and we no longer do the "kitchen sink" approach of throwing in every cipher that "seems reasonable"

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Aug 2016 14:40:23 -0400

Michael:

Jim suggested that AES-256 as SHOULD+.  We have seen people select AES-128 or AES-256, but ignore the middle ground in other applications.  So, AES-192 will not help with the interoperability goal.

Russ

---

From: Russ Housley <[email-masked]>
Date: Mon, 1 Aug 2016 14:41:02 -0400

Jim:

Yes, that would be fine with me.

Russ

---

From: Jim Schaad <[email-masked]>
Date: Mon, 1 Aug 2016 11:58:50 -0700

I would say that as a general rule, we should always have a minimum of two
MUST algorithms everywhere so that we have a backup in case of failure.  I
would therefore accept arguments about having three items but not two items.

Jim

> From: Spasm [mailto:[email-masked]] On Behalf Of Blake Ramsdell
> Sent: Monday, August 01, 2016 11:21 AM
> I am going to ask this for every MUST that has multiple options for every
> algorithm type, so you might consider pre-emptively having a statement for
why
> there are multiple options.
> 
> I'll further elaborate that I think there should be one for compatibility
with that
> old algorithm that we used to use, one for teh new hotness algorithm that
we're
> going to use now, and one SHOULD or

---

From: Michael Richardson <[email-masked]>
Date: Tue, 02 Aug 2016 07:55:28 -0400

> would therefore accept arguments about having three items but not two

okay, but I don't entirely consider AES128 and AES256 to be different
algorithms.  Depends upon the nature of the failure.  CGM (or other CTR-type
modes) and not-CGM are more different, but, the right failure could take them
all out at the same time, I think.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Jim Schaad <[email-masked]>
Date: Tue, 2 Aug 2016 09:14:38 -0700

> From: Spasm [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: Tuesday, August 02, 2016 4:55 AM
> Cc: 'Blake Ramsdell' <[email-masked]>; 'SPASM' <[email-masked]>
>     > would therefore accept arguments about having three items but not
two
>     > items.
algorithms.
> Depends upon the nature of the failure.  CGM (or other CTR-type

I would agree with you that the different modes with AES are not really
different algorithms as the core primitive is the same.  I don't believe
that we are yet justified to making ChaCha20 into a MUST algorithm. 

We cannot get rid of CBC because of backwards compatibility.  We need to get
into GCM for AEAD support, which is a significant step forward.  I may be
overly agreessive about trying to jump to all 256 bit key lengths however.

Im

> 
> --
> Michael Richardson <[email-masked]>, Sandelman Software Works  -=
> IPv6 IoT consulting =-
> 
>

---

From: Sean Turner <[email-masked]>
Date: Tue, 2 Aug 2016 15:16:40 -0400

> overly agreessive about trying to jump to all 256 bit key lengths however.

Maybe I’m not on the same page as everybody else, but I’ve been thinking that we’re going to add AuthEnvelopedData as the MUST implement for this version and retain EnvelopedData, SignedData, and EnvelopedData+SignedData for backward compatibility.  If that’s the case do we need to up the CBC sizes at all?

spt