Subject: [jose] AEAD algorithms

From: "Jim Schaad" <[email-masked]>
Date: Tue, 17 Jan 2012 17:12:04 -0800

I would like to see a mandatory AEAD algorithm. While I would prefer the use
of AES-GCM, one algorithm that could be considered is the composite one
purposed by Peter Gutmann in RFC 6476 which does the following:

States separate encryption and MAC algorithms to be used
Defines a method of deriving separate keys for the encryption and MAC
algorithms from a single common key transported to the end user.

This makes it appear as a standard AEAD algorithm but it is made up from
common primitives rather than using a special mode that is not widely
distributed.

Jim

---

From: John Bradley <[email-masked]>
Date: Tue, 17 Jan 2012 22:26:03 -0300

I agree that is needed for JWE.

The goal of this draft was to add nothing new to the existing JWE & JWS specs.

I expect that the next draft will add a MTI AEAD algorithm.

John B.
On 2012-01-17, at 10:12 PM, Jim Schaad wrote:

> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jan 2012 09:58:57 +0200

Hi Jim, 

when you say "mandatory" what do you mean? 

Already for a while now we are not putting mandatory to implement nor mandatory to use algorithms in our specifications anymore. 

See also my mail to the OAuth list on that topic:
http://www.ietf.org/mail-archive/web/oauth/current/msg08019.html

Ciao
Hanns

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Jan 2012 00:44:03 -0800

<non chair>

It is not quite true that we do not put mandatory to implement algorithms in
our specs any more.  The requirement to have mandated algorithms varies
depending on the specification and the purpose to which it is to be used.
It is true that PKIX and CMS do not have mandated algorithms, but S/MIME,
TLS and DANE do.  The difference is generally a question of are we just
defining a frame work or a protocol.  

In this case we are separating the algorithms from the structure, but I
think that the group as a whole may decide that it will still need to
specify a set of mandatory algorithms in order to promote interoperability
as a library.  Documents which build on top, such as the JSON token document
might or might not specify the same, different or any algorithms (inheriting
what we do). 

I have not yet formulated a final personal opinion, but the language I have
heard in the past on the list is towards specifying mandatory algorithms.

Jim

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, January 17, 2012 11:59 PM
> To: Jim Schaad
> Cc: Hannes Tschofenig; [email-masked]
> Subject: Re: [jose] AEAD algorithms
> 
> Hi Jim,
> 
> Already for a while now we are not putting mandatory to implement nor
> mandatory to use algorithms in our specifications anymore.
> 
> > I would like to see a mandatory AEAD algorithm. While I would prefer
> > the use of AES-GCM, one algorithm that could be considered is the
> > composite one purposed by Peter Gutmann in RFC 6476 which does the
> following:
> >
> > States separate encryption and MAC algorithms to be used Defines a
> > method of deriving separate keys for the encryption and MAC algorithms
> > from a single common key transported to the end user.
> >
> > This makes it appear as a standard AEAD algorithm but it is made up
> > from common primitives rather than using a special mode that is not
> > widely distributed.
> >
> > Jim
> >
> >

---

From: Mike Jones <[email-masked]>
Date: Wed, 18 Jan 2012 09:02:12 +0000

As a data point, the current specs DO specify mandatory-to-implement algorithms to promote interoperability.  See http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-00.html#SigningAlgs and http://self-issued.info/docs/draft-ietf-jose-json-web-algorithms-00.html#EncryptingAlgs.  The key sentences are:

For JWS:  Of these algorithms, only HMAC SHA-256 MUST be implemented by conforming JWS implementations. It is RECOMMENDED that implementations also support the RSA SHA-256 and ECDSA P-256 SHA-256 algorithms. Support for other algorithms and key sizes is OPTIONAL.

For JWE:  Of these algorithms, only RSA-PKCS1-1.5 with 2048 bit keys, AES-128-CBC, and AES-256-CBC MUST be implemented by conforming JWE implementations. It is RECOMMENDED that implementations also support ECDH-ES with 256 bit keys, AES-128-GCM, and AES-256-GCM. Support for other algorithms and key sizes is OPTIONAL.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jim Schaad
Sent: Wednesday, January 18, 2012 12:44 AM
To: 'Hannes Tschofenig'
Cc: [email-masked]
Subject: Re: [jose] AEAD algorithms

<non chair>

It is not quite true that we do not put mandatory to implement algorithms in our specs any more.  The requirement to have mandated algorithms varies depending on the specification and the purpose to which it is to be used.
It is true that PKIX and CMS do not have mandated algorithms, but S/MIME, TLS and DANE do.  The difference is generally a question of are we just defining a frame work or a protocol.  

In this case we are separating the algorithms from the structure, but I think that the group as a whole may decide that it will still need to specify a set of mandatory algorithms in order to promote interoperability as a library.  Documents which build on top, such as the JSON token document might or might not specify the same, different or any algorithms (inheriting what we do). 

I have not yet formulated a final personal opinion, but the language I have heard in the past on the list is towards specifying mandatory algorithms.

Jim

> > method of deriving separate keys for the encryption and MAC

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jan 2012 11:10:46 +0200

While I disagree with you even in case of TLS I definitely think that JOSE should list mandatory-to-implement or mandatory-to-use algorithms in the main documents. You can always write an additional document that lists what algorithms are recommended for usage in specific environments and update that document every few years.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 18 Jan 2012 12:36:54 +0100

> While I disagree with you even in case of TLS I definitely think that JOSE should list mandatory-to-implement or mandatory-to-use algorithms in the main documents. You can always write an additiona…

Well, I don't know (or did you mean "should not"?).

For constrained devices with current chip sets, there is a very strong bias in favor of AES-CCM.
I don't think any MTI algorithms should be defined without also a bit more explicit about the area of application.
(Yes, we do want to use JOSE in constrained devices.  That is hard enough!)

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 18 Jan 2012 13:52:50 +0200

Hi Carsten, 

that's exactly the problem: for some environments certain algorithms are best suited and in others they are not. 

You have to describe the envisioned environment and make the recommendation for it 
Then, you also want to avoid updating a protocol specification whenever you want to add a new use case or when algorithms are out-of-fashion.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jan 2012 14:44:20 -0800

> While I disagree with you even in case of TLS I definitely think that JOSE should list mandatory-to-implement or mandatory-to-use algorithms in the main documents. You can always write an additiona…

I don't understand what you disagree with in the case of TLS.

TLS does define an MTI. See: http://tools.ietf.org/html/rfc5246#section-9

Perhaps your argument is that TLS shouldn't do this. However, that's
quite different from the statement that we are not doing so, with which,
like Jim, I don't agree.

-Ekr