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

[Nat Sakimura <[e-mail]>]

"JSON Web Signature and Message Authentication" is a bit verbose, but
accurate so I like it.

=nat

On Wed, Nov 16, 2011 at 8:25 PM, David McGrew <[e-mail]> wrote:

> 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<https://www.ietf.org/mailman/listinfo/jose>
>> ______________________________**_________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>>
>
> ______________________________**_________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/jose<https://www.ietf.org/mailman/listinfo/jose>
>



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