Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption

[David McGrew <[e-mail]>]

Hi Mike,

On Nov 15, 2011, at 5:57 PM, Mike Jones wrote:

> Upon reflection since Monday's meeting, I believe that the draft  
> title should stay "JSON Web Signature" (as Tony pointed out,  
> "Signing" is in the WG's name!)

we should not be concerned about consistency with the WG name, but  
instead about the perceptions of the reader.  We can't blame the  
reader for expecting an RFC with "signatures" in its name to provide  
asymmetric authentication.  Will implementations that include the  
symmetric message authentication code, but lack any actual signature  
mechanisms, be able to claim conformance to the specification?

> but the text should be clear that the spec describes both how to  
> perform digital signatures and how to perform HMAC operations).  It  
> will no longer use the term "signing" when referring to HMAC  
> operations.
>

Great, that's a key point.

> As Eric Rescorla pointed out during the meeting, the problem with  
> splitting out HMAC into a different spec is that the preparation of  
> the content is essentially identical between the two kinds of  
> operations.  The amount of duplication resulting wouldn't be doing  
> the users of the specs any favors.

Avoiding duplication is a good goal.  Another way to achieve it, while  
being more clear about what conformance to the spec means, is to have  
two drafts, with the MAC draft using definitions from the Signature  
draft.  Say, the Signature draft could have a section or two that  
applies to both, and the MAC draft references those sections.

If there is only going to be one draft, then I strongly encourage the  
WG to use a generic term like "authentication" in the title, or to  
have the title describe both security mechanisms: "JSON Web Signature  
and Message Authentication".

David

>
> 				-- Mike
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Anthony Nadalin
> Sent: Tuesday, November 15, 2011 5:50 PM
> To: David McGrew; [e-mail]
> Subject: Re: [jose] comments on draft-jones-json-web-signature and  
> draft-jones-json-web-encryption
>
> At the same time we don't want to confuse folks the other way to  
> have them think we are not addressing signature. The WG name does  
> have signing in it. One option would be to split out the MAC from  
> the signing
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of David McGrew
> Sent: Tuesday, November 15, 2011 4:40 AM
> To: [e-mail]
> Subject: [jose] comments on draft-jones-json-web-signature and draft- 
> jones-json-web-encryption
>
> Hi
>
> I would like to contribute the following comments.  I have not been  
> closely following the WG, so apologies in advance if I'm rehashing  
> something.
>
> The json-web-signature draft should be changed by using the more  
> generic "authentication" instead of "signature", as suggested in
> Section 9.   HMAC is a (symmetric) message authentication code, and
> not an (asymmetric) digital signature algorithm.  See RFC 4949 for  
> instance for the appropriate definitions.  Calling HMAC a signature  
> method will confuse readers going forward and potentially set  
> incorrect expectations. I suggest the following changes (not because  
> I think these are the only good alternatives, but because I want to be
> constructive):
>
> "JSON Web Signature" -> "JSON Web Authentication"
> "sign" -> "authenticate"
> "signing" -> "authenticating"
> "signature" -> "authentication data"
>
> The security considerations of json-web-signature should explain the  
> difference between symmetric and asymmetric encryption.
>
> Section 9 mentions the possibility of including an unkeyed checksum  
> based on SHA-256.  If that is done, then that will potentially  
> confuse the issue further.  What would the value of that checksum  
> be, and
> would it be a security mechanism?   If it is defined, I suggest that
> it be done in a different draft.
>
> Why are we allowing unauthenticated encryption in draft-jones-json- 
> web-
> encryption?   Authenticated Encryption with Associated Data (AEAD) is
> recommended (in the form of AES-GCM) in the draft, and it avoids all  
> sorts of security issues that are present with unauthenticated  
> encryption (besides being theoretically vulnerable, it has fallen  
> victim to practical attacks [1][2][3][4][5][6][7][8]).  Note that  
> some of these attacks apply when encryption is loosely bound to  
> authentication.  I suggest that AEAD be the only encryption method,  
> and that an RFC 5116 interface be included.  Since GCM is  
> recommended, the interface is already there, but not called out.   
> Omitting unauthenticated encryption will simplify the spec, and  
> improve security.  If there is some percieved issue with AES-GCM,  
> there are other AEAD algorithms that can be used, AES-SIV (synthetic  
> IV mode)
> for instance, or a generic CBC+HMAC composition.   In any case, I
> offer to help craft and/or review this text.
>
> A minor point: JWE recommends AES-GCM; why not have json-web- 
> signature recommend AES-GMAC?
>
> json-web-signature says that "Related encryption capabilities are
> described in the separate JSON Web Encryption (JWE) specification".
> The JWE specification says that "In general, senders SHOULD sign the  
> message and then encrypt the result (thus encrypting the
> signature)".   There ought to be better recommendations for security.
> For instance, encryption without authentication should be disallowed.
>
> regards,
>
> David
>
> --
>
>
> [1] Vaudenay, "Security Flaws Induced by CBC Padding Applications to  
> SSL, IPSEC, WTLS...", EUROCRYPT 2002.
>
> [2] Rizzo, Duong, "Practical Padding Oracle Attacks", Black Hat  
> Europe, 2010.
>
> [3] Jager, Somorovsky, "How To Break XML Encryption", 18th ACM  
> Conference on Computer and Communications Security (CCS), 2011.
>
> [4] Bellare, Kohno, Namprempre, "Breaking and provably repairing the  
> SSH authenticated encryption scheme: A case study of the Encode- 
> then- Encrypt-and-MAC paradigm", ACM Transactions on Information and  
> System Security, May 2004.
>
> [5] Rizzo, Thai, "BEAST: Surprising crypto attack against HTTPS",  
> Ekoparty, 2011.
>
> [6] Bellovin, “Problem Areas for the IP Security Protocols”,  
> Sixth Usenix Unix Security Symposium, 1996.
>
> [7] Paterson, Yau, “Cryptography in theory and practice: The case  
> of encryption in IPsec”, EUROCRYPT 2006,
>
> [8] Degabriele, Paterson, "Attacking the IPsec Standards in  
> Encryption- only Configurations", IEEE Symposium on Security and  
> Privacy, 2007.
>
>
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose