Re: [jose] some more comments on the jose drafts ...

Nat Sakimura <sakimura@gmail.com> Mon, 12 December 2011 16:05 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473F021F8B53 for <jose@ietfa.amsl.com>; Mon, 12 Dec 2011 08:05:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S+GiNX50S2RV for <jose@ietfa.amsl.com>; Mon, 12 Dec 2011 08:05:33 -0800 (PST)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9211721F8B0C for <jose@ietf.org>; Mon, 12 Dec 2011 08:05:32 -0800 (PST)
Received: by laah2 with SMTP id h2so1406146laa.31 for <jose@ietf.org>; Mon, 12 Dec 2011 08:05:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hsY48c9nJGR6r+LhWlypehyfQHsc8rD81jt0OQSbryg=; b=FoGpkmW0dmxElvhvO6lzIqrQVlkHJ4WyTz9Di7VhQ3VU5JhUTbSUH3dvdKJnTvRTnv +o8szt/fFmzNfuTa4MFaVqcnNzxHT5No91MXsG5jhuH1vQay9TWgQ714CPgs7CauDYLN f/9YfSiRxh3ei8nTaK0gY3m1SurNaWvJAi09M=
MIME-Version: 1.0
Received: by 10.152.134.50 with SMTP id ph18mr12516559lab.1.1323705931565; Mon, 12 Dec 2011 08:05:31 -0800 (PST)
Received: by 10.152.11.38 with HTTP; Mon, 12 Dec 2011 08:05:31 -0800 (PST)
In-Reply-To: <4EE52166.30701@rub.de>
References: <4EE52166.30701@rub.de>
Date: Tue, 13 Dec 2011 01:05:31 +0900
Message-ID: <CABzCy2ABzX0AFTx8epR6SWkPtHt4ith4YHgOqtgHgZUwUpD0Sg@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
To: Juraj Somorovsky <juraj.somorovsky@rub.de>
Content-Type: multipart/alternative; boundary="f46d042de7afd6895c04b3e74d9b"
Cc: jose@ietf.org
Subject: Re: [jose] some more comments on the jose drafts ...
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Dec 2011 16:05:34 -0000

On Mon, Dec 12, 2011 at 6:32 AM, Juraj Somorovsky
<juraj.somorovsky@rub.de>wrote:

> Hi,
>
> I would also like to contribute with some comments to the jose drafts. I
> am not following closer the jose evolution, but I hope my comments will
> be useful.
>
> 1) usage of unauthenticated encryption: as already written by David, the
> encryption algorithms should not be used without authentication and
> integrity check. JOSE standards should not allow the usage of AES-CBC.
> Otherwise, it is only a matter of time before we will see some practical
> attacks.
>

I fully agree that encryption should be used only with integrity checking.
In the ideal world, we would only have to use some mode like GCM, but
unfortunately the support is yet to become wide spread. In most platforms,
it is likely that the develop has to rely on something like CBC whose
support is much more wide spread. Under this cercumstances, we would have
to support CBC with integrity checks. So, doing encryption and integrity
check (optional for GCM etc., and MUST for CBC) is the way to go, IMHO. To
do so, instead of just using CEK, include the CMK in the header and use it
to create CEK and CIK.


> 2) usage of RSA1_5: Is it really necessary to have this algorithm in the
> standard? Would it not be enough to have RSA-OAEP?
> The problem with RSA1_5 is that it is vulnerable to side-channel attacks
> described by Daniel Bleichenbacher [1]. These attacks could be simply
> mitigated in SSL or similar protocols. However, application of these
> mitigation techniques in json could be more complicated and would cause
> many implementation problems. Therefore, I would suggest only to use
> RSA-OAEP. (there is a next attack on XML Encryption coming soon, it
> describes these problems)
>

As to the support of PKCS 1.5 is concerned, again, it is the same problem
as the support of GCM. The platform that only supports PKCS 1.5 is still
wide spread. Of course we may use this spec to whip the providers and
software vendors to build the support for a more decent algorithms but that
will severely limit the adoption of the spec in the initial phase. I think
we should support PKCS 1.5 as a base line which is a MUST, and strongly
recommend more decent ones and put some comment in the security
consideration as well.


> 3) Streaming-based signature creation: I am not that familiar with json
> and all its application scenarios (therefore I am sorry, if this is out
> of scope). I can imagine that you want to transport a large signed
> document. If you generate the document on the fly, you would probably
> want to send it directly to the recipient without caching it in the
> memory. However, this would not be possible using your signature
> standard, as you have to put the whole document to the memory, create a
> signature over this document, put this signature into the header, and
> lastly send the whole file with signature headers.
> As I have seen in your standard, it is not allowed to put the signature
> value behind the signed document (please correct me if I am wrong).
> Similar problems in SOAP messages were discussed also by Sean Mullan [2].
>
>
> I hope my comments will be useful.
>
> Best Regards
> Juraj
>
>
> [1] D. Bleichenbacher.  Chosen Ciphertext Attacks Against Protocols
> Based on the RSA Encryption Standard PKCS #1.
>
> [2] S. Mullan: XML Signature Performance and  One-Pass Processing Issues
> http://www.w3.org/2007/xmlsec/ws/slides/01-mullan-sun/Overview.pdf
>
> --
> M.Sc. Juraj Somorovsky
>
> Lehrstuhl für Netz- und Datensicherheit
> Ruhr Universität Bochum
> -----------------------------------
> Universitätsstr. 150, Geb. ID 2/411
> D-44780 Bochum
>
> Telefon: +49 (0) 234 / 32-26551
> Fax: +49 (0) 234 / 32-14347
> http://www.nds.rub.de
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>



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