Subject: Re: [OAUTH-WG] Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27: (with COMMENT)

From: Mike Jones <[email-masked]>
Date: Mon, 6 Oct 2014 07:54:17 +0000

Thanks for your review, Ted.  I'm adding the working group to the thread so they're aware of your comments.

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Thursday, October 02, 2014 6:58 AM
> To: The IESG
> Cc: [email-masked]; draft-ietf-oauth-json-web-
> [email-masked]
> Subject: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27:
> (with COMMENT)
> 
> Ted Lemon has entered the following ballot position for
> draft-ietf-oauth-json-web-token-27: No Objection
> 
> When responding, please keep the subject line intact and reply to all email
> addresses included in the To and CC lines. (Feel free to cut this introductory
> paragraph, however.)
> 
> 
> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> http://datatracker.ietf.org/doc/draft-ietf-oauth-json-web-token/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
>    The suggested pronunciation of JWT is the same as the English word
>    "jot".
> 
> I would have gone with "jute".   :)   Also, this doesn't belong in the
> abstract. It appears to have crept in as a result of cutting and pasting the
> introduction into the abstract.

You're not the first person with knowledge of Welsh to make the same comment. :-)  (And this is a Jones responding...)

I'll plan to remove the sentence from the abstract.

> Is there any reason not to just require this:
> 
>    While syntactically the signing and encryption operations for Nested
>    JWTs may be applied in any order, normally senders should sign the
>    message and then encrypt the result (thus encrypting the signature).
>    This prevents attacks in which the signature is stripped, leaving
>    just an encrypted message, as well as providing privacy for the
>    signer.  Furthermore, signatures over encrypted text are not
>    considered valid in many jurisdictions.
> 
> When does it make sense not to do it this way?

Sometimes authenticated encryption alone is good enough without requiring a signature.  Different applications will have different requirements.  So while this section discussion the applicable considerations, the working group felt that it was going too far to make this prescriptive.

				Thanks again,
				-- Mike

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Oct 2014 15:48:44 -0400

> Sometimes authenticated encryption alone is good enough without requiring a signature.  Different applications will have different requirements.  So while this section discussion the applicable con…

But if you don't need to sign the message, why sign it?

---

From: Mike Jones <[email-masked]>
Date: Tue, 7 Oct 2014 05:29:42 +0000

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, October 06, 2014 12:49 PM
> To: Mike Jones
> Cc: The IESG; [email-masked]; draft-ietf-oauth-json-web-
> [email-masked]; [email-masked]
> Subject: Re: Ted Lemon's No Objection on draft-ietf-oauth-json-web-token-27:
> (with COMMENT)
> 
> > Sometimes authenticated encryption alone is good enough without requiring a
> signature.  Different applications will have different requirements.  So while this
> section discussion the applicable considerations, the working group felt that it
> was going too far to make this prescriptive.
> 

The working group isn't advocating signing the token if it's not necessary.  The clause we're discussing is just intended to provide guidance to application architects in the case that both signing and encryption are necessary.

I propose that we add language about "If both signing and encryption are necessary" in order to make the context of this advice clear.  Would that resolution be acceptable to you, Ted?

				-- Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2014 10:26:46 -0400

> I propose that we add language about "If both signing and encryption are necessary" in order to make the context of this advice clear.  Would that resolution be acceptable to you, Ted?

So you're saying that if signing and encryption are necessary, signing before encrypting is RECOMMENDED because of the attacks you described?   I guess I'm okay with that.

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Oct 2014 11:57:04 -0300

In XMLdsig if you are using a non AEAD encryption algorithm, you may well need to sign over the encrypted information to protect it from modification.

In SAML some people sign the assertion, encrypt the assertion, and then sign the message.

The main reason for signing inside the encryption, tends to be legal in that a signature over something you can't see is not considered enforceable most places.
So if you are signing for non repudiation then inside the encryption is typically required.

As JOSE only supports AEAD encryption over-signing to protect the encrypted message from tampering is not required.
So if you require both signing to identify the sender and encryption for confidentiality then sign and then encrypt is the best bet. 

On the other hand we can't preclude other valid use cases if someone needs to encrypt and then sign so that perhaps intermediate hops can validate the signature.

That is why it is should and not must.

Regards
John B.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2014 12:13:22 -0400

> So if you are signing for non repudiation then inside the encryption is typically required.

The document currently warns that if the signature is not encrypted, it would be possible to encrypt the message, sign it, and then an MiTM could strip the signature.   This seems to contradict what you are saying here.   Not being an expert, I am probably missing something, but what you actually recommend should be consistent; if in fact in the scenario you are talking about the stripping of the signature wouldn't buy the attacker anything, you should say so.

To be clear, what I am asking for is just that the document make sense to someone who doesn't know all the properties of all the crypto algorithms.   Based on what I've heard so far, I'm not suggesting that you need to add any new requirements.   And I'm just asking, so if I'm really talking through my hat, you are free to just ignore me! :)

---

From: John Bradley <[email-masked]>
Date: Tue, 7 Oct 2014 14:14:48 -0300

Section 11.2 makes both points.

Encrypting and then signing is likely only a special case used by some applications that are configured to understand what is going on.  
If you are going to do it in that order you would want to be certain that you don't accept a JWT that has no signature.

Stripping a signature shouldn't buy an attacker anything with a properly configured recipient.   However it might possibly confuse some application logic.

We are making a best practice recommendation in 11.2 but there are circumstances where it might make sense for a application to do something else.

John B.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2014 13:30:00 -0400

> Encrypting and then signing is likely only a special case used by some applications that are configured to understand what is going on. 

This isn't really responsive to what I said.   As I said, I'm just asking you to be consistent, not to change the requirements.   I don't think that text in the security considerations section addresses the inconsistency I'm talking about in a different section.   That said, please don't continue to talk to me about this.   If you think there's an action to take, take it.   If not, no need to continue trying to explain.   I'm okay with it either way.

---

From: Mike Jones <[email-masked]>
Date: Wed, 8 Oct 2014 01:06:06 +0000

> Sent: Tuesday, October 07, 2014 10:30 AM
> To: John Bradley
> Cc: The IESG; Mike Jones; [email-masked];
> [email-masked]; [email-masked]
> > Encrypting and then signing is likely only a special case used by some
> applications that are configured to understand what is going on.
> 
> This isn't really responsive to what I said.   As I said, I'm just asking you to be
> consistent, not to change the requirements.   I don't think that text in the
> security considerations section addresses the inconsistency I'm talking about in a
> different section.   That said, please don't continue to talk to me about this.   If
> you think there's an action to take, take it.   If not, no need to continue trying to
> explain.   I'm okay with it either way.

I'll plan to take the action described yesterday that you said you were OK with - adding language about "If both signing and encryption are necessary" in order to make the context of this advice clear.  I believe that that will improve the understanding of this guidance by many readers.

Thanks again for the discussion, Ted.

				-- Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 7 Oct 2014 21:25:54 -0400

Thank you, both! I'm glad to see this one resolved.

FYI - I'll be at the Grace Hopper Celebration through Friday evening and
may be slow to respond, but will be following along.

On Tue, Oct 7, 2014 at 9:06 PM, Mike Jones <[email-masked]>
wrote:

> I'll plan to take the action described yesterday that you said you were OK
> with - adding language about "If both signing and encryption are necessary"
> in order to make the context of this advice clear.  I believe that that
> will improve the understanding of this guidance by many readers.
>

-- 

Best regards,
Kathleen

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Oct 2014 21:30:34 -0400

> I'll plan to take the action described yesterday that you said you were OK with - adding language about "If both signing and encryption are necessary" in order to make the context of this advice cl…

Sounds good, thanks!   It's hard to keep track of the discussion once the review is done... :)