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

[Nat Sakimura <[e-mail]>]

+1

Also, Re:David's proposal for use of word "Authentication": I am ok with
"Message Authentication" but against just using stand alone
"Authentication". It is a way too overloaded word and causes unnecessary
confusion.

On Wed, Nov 16, 2011 at 9:57 AM, Mike Jones <[e-mail]>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!) 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.
>
> 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.
>
>                                -- 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
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>



-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en