Return-Path: 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 75D6811E8127 for ; Wed, 4 Sep 2013 15:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Rj5yiTMNTYql for ; Wed, 4 Sep 2013 15:51:01 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6011E811E for ; Wed, 4 Sep 2013 15:51:00 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m6so1317709oag.32 for ; Wed, 04 Sep 2013 15:50:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cdNvmvLuUz5o2zT4s20b3WUYXjNw5nGHiW01twAUkrU=; b=dSobvE/DzQRipH+A2o/cbGKJbpJ/b2oJydC1OLSRz1kODF4Pf7CA+pdZHQNuzBv6+o 2t65Ewdt6loaSaTd3ST1P8xgmas5fGmjET5RgUvFRCvQ4SMGtBEfpEAQVyJMzpHlq51J AIJoiod0QFlZtP9Mi7Vb2XlVsf0cwQpn/qaBT8wzJBnGYJew2XgIrtmzYKjbV58+W+zr aSa5U62lYZfBspPuMOgZd59DQd1DpMUeu54ltmTZbBwYb46dS+OvFLLOS1995Efp1n1+ kIxBaqVOXKoqtixHTNliZoKdVyA+/x9r+HR3XlxHhjgmJa1RhRMtDge3tlBgNnrCzGZ1 7xkw== X-Gm-Message-State: ALoCoQn1ITJpFCGAG8JyPU6C64dIat6Xco3/KL0ZSYI0SpYTAQVsMlePylqCiMr/+Yrkw3zKgUz5 MIME-Version: 1.0 X-Received: by 10.182.18.9 with SMTP id s9mr4092153obd.15.1378335059359; Wed, 04 Sep 2013 15:50:59 -0700 (PDT) Received: by 10.60.31.74 with HTTP; Wed, 4 Sep 2013 15:50:59 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436C2EA801@TK5EX14MBXC291.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B16804296739436C2EB1D4@TK5EX14MBXC291.redmond.corp.microsoft.com> Date: Wed, 4 Sep 2013 18:50:59 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c2d6a098405604e596a338 Cc: "jose@ietf.org" Subject: Re: [jose] Text about applications and "alg":"none" X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2013 22:51:11 -0000 --001a11c2d6a098405604e596a338 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Also, note this text needs to appear in JWS, not JWA, since it's a general requirement on JWS implementations. So in addition to requiring implementations to be unnecessarily complex, it also breaks the clean separation between those documents. On Wed, Sep 4, 2013 at 6:45 PM, Richard Barnes wrote: > I think it's important to emphasize that an implementation MUST NOT allow > a global setting. In fact, I would argue that if "none" is in the > acceptable algorithm list, it MUST be the only thing in the list. Any > other way, and you end up with downgrade. > > --Richard > > > On Tue, Sep 3, 2013 at 6:47 PM, Mike Jones w= rote: > >> Your proposed text seems overly verbose. In particular, I believe >> you=92ll find that the text I proposed already means the same thing / mo= dulo >> the difference between RECOMMENDED and MUST. If the WG wants a MUST we >> could do that instead of RECOMMENDED. We can discuss that on tomorrow= =92s >> call.**** >> >> ** ** >> >> The correspondence is as follows:**** >> >> Your sentence 1 is covered in my sentence 1.**** >> >> Your sentence 2 is covered in my sentence 1.**** >> >> Your sentence 3 is covered in my sentences 1 & 2. In particular, the >> =93per-object basis=94 is already covered by =93in a JWS object=94. (If= it were >> not on a per-object basis, it would have said something like =93in all J= WS >> objects=94.**** >> >> ** ** >> >> Cheers,*= * >> ** >> >> -- Mike*= * >> ** >> >> ** ** >> >> *From:* Richard Barnes [mailto:rlb@ipv.sx] >> *Sent:* Tuesday, September 03, 2013 1:33 PM >> *To:* Mike Jones >> *Cc:* jose@ietf.org >> *Subject:* Re: [jose] Text about applications and "alg":"none"**** >> >> ** ** >> >> This text is still far too weak, and does not reflect what I remember EK= R >> saying (in particular, there is no MUST). It does not address the attac= k >> where an application may, in general, be willing to accept both signed a= nd >> unsigned content, but each in specific contexts. Proposed text:**** >> >> ** ** >> >> """**** >> >> JWS implementations MUST provide an interface for applications to specif= y >> a list of "alg" values that are acceptable for the validation of a given >> JWS object. JWS implementations MUST NOT indicate that a JWS object is >> valid if the "alg" value for the object is "none", unless the applicatio= n >> has specifically indicated that the value "none" is acceptable for the >> particular JWS object being validated. Applications using "none" MUST >> indicate support on a per-object basis, in order to avoid downgrade atta= cks >> that arise if more broadly-applicable preferences are specified.**** >> >> """**** >> >> ** ** >> >> I continue to believe that this is far too subtle, and that applications >> are very likely to get it wrong. It is far simpler and safer to require >> that a JWS implementation MUST reject an object with "alg":"none", and h= ave >> another content type for unsigned content.**** >> >> ** ** >> >> Also, if "none" is going to remain, then it needs to be OPTIONAL. Given >> all the above limitations, I don't see how you could justify it being >> mandatory.**** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> ** ** >> >> On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones >> wrote:**** >> >> I took an action item during the last call to write text along the lines >> suggested by ekr about applications and "alg":"none". I propose that th= e >> following text be included:**** >> >> **** >> >> It is RECOMMENDED that libraries provide applications a means of >> specifying the list of acceptable algorithms used in a JWS object in a w= ay >> that causes inputs using algorithms outside the specified set to be >> rejected. In particular, it is intended for applications to use this >> mechanism to exclude accepting inputs using "alg":"none" in security >> contexts where non-integrity protected inputs are not acceptable.**** >> >> **** >> >> Feedback/proposed wording refinements welcomed.**** >> >> **** >> >> -- Mike*= * >> ** >> >> **** >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > > --001a11c2d6a098405604e596a338 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Also, note this text needs to appear in JWS, not JWA, sinc= e it's a general requirement on JWS implementations. =A0So in addition = to requiring implementations to be unnecessarily complex, it also breaks th= e clean separation between those documents. =A0


On Wed, Sep 4= , 2013 at 6:45 PM, Richard Barnes <rlb@ipv.sx> wrote:
I think it's important to emphasize that an implementa= tion MUST NOT allow a global setting. =A0In fact, I would argue that if &qu= ot;none" is in the acceptable algorithm list, it MUST be the only thin= g in the list. =A0Any other way, and you end up with downgrade.

--Richard


On Tue, Sep 3, 2013 at 6:47 PM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:

Your proposed text seems = overly verbose.=A0 In particular, I believe you=92ll find that the text I p= roposed already means the same thing / modulo the difference between RECOMMENDED and MUST.=A0 If the WG wants a MUST we could do that i= nstead of RECOMMENDED.=A0 We can discuss that on tomorrow=92s call.<= u>

=A0<= /p>

The correspondence is as = follows:

Your sentence 1 is covere= d in my sentence 1.

Your sentence 2 is covere= d in my sentence 1.

Your sentence 3 is covere= d in my sentences 1 & 2.=A0 In particular, the =93per-object basis=94 i= s already covered by =93in a JWS object=94.=A0 (If it were not on a per-obj= ect basis, it would have said something like =93in all JWS objects=94.<= u>

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Cheers,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, September 03, 2013 1:33 PM
To: Mike Jones
Cc: jose@ietf.org=
Subject: Re: [jose] Text about applications and "alg":&quo= t;none"

=A0

This text is still far too weak, and does not reflec= t what I remember EKR saying (in particular, there is no MUST). =A0It does = not address the attack where an application may, in general, be willing to = accept both signed and unsigned content, but each in specific contexts. =A0Proposed text:

=A0

"""

JWS implementations MUST provide an interface for ap= plications to specify a list of "alg" values that are acceptable = for the validation of a given JWS object. =A0JWS implementations MUST NOT i= ndicate that a JWS object is valid if the "alg" value for the object is "none", unless the application has speci= fically indicated that the value "none" is acceptable for the par= ticular JWS object being validated. =A0Applications using "none" = MUST indicate support on a per-object basis, in order to avoid downgrade attacks that arise if more broadly-applicable preferences are specified.

"""

=A0

I continue to believe that this is far too subtle, a= nd that applications are very likely to get it wrong. =A0It is far simpler = and safer to require that a JWS implementation MUST reject an object with &= quot;alg":"none", and have another content type for unsigned content.

=A0

Also, if "none" is going to remain, then i= t needs to be OPTIONAL. =A0Given all the above limitations, I don't see= how you could justify it being mandatory.

=A0

--Richard

=A0

=A0

On Tue, Sep 3, 2013 at 2:02 PM, Mike Jones <Michael.Jones@m= icrosoft.com> wrote:

I took an action item during the last call to write = text along the lines suggested by ekr about applications and "alg"= ;:"none".=A0 I propose that the following text be included:

=A0

It is RECOMMENDED that libraries provide applications a means of specifying= the list of acceptable algorithms used in a JWS object in a way that cause= s inputs using algorithms outside the specified set to be rejected.=A0 In p= articular, it is intended for applications to use this mechanism to exclude accepting inputs using "alg":&q= uot;none" in security contexts where non-integrity protected inputs ar= e not acceptable.

=A0

Feedback/proposed wording refinements welcomed.

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 -- Mike

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0



--001a11c2d6a098405604e596a338--