Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 06 October 2014 21:18 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D6591A8A25; Mon, 6 Oct 2014 14:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.686
X-Spam-Level:
X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQtSf9157dVG; Mon, 6 Oct 2014 14:17:59 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C66671A1A19; Mon, 6 Oct 2014 14:17:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2B0B1BE09; Mon, 6 Oct 2014 22:17:58 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qceCC2SiL8_r; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Received: from [10.87.48.8] (unknown [86.41.57.167]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B2C63BE07; Mon, 6 Oct 2014 22:17:55 +0100 (IST)
Message-ID: <54330703.3050806@cs.tcd.ie>
Date: Mon, 06 Oct 2014 22:17:55 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: Jim Schaad <ietf@augustcellars.com>, 'Mike Jones' <Michael.Jones@microsoft.com>, 'The IESG' <iesg@ietf.org>
References: <20141002103700.19412.21857.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C06@TK5EX14MBXC286.redmond.corp.microsoft.com> <00d801cfe1a8$63e45f20$2bad1d60$@augustcellars.com>
In-Reply-To: <00d801cfe1a8$63e45f20$2bad1d60$@augustcellars.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/Q-TEHkernFew6H_QeVnU3T1ERZY
Cc: jose-chairs@tools.ietf.org, jose@ietf.org, draft-ietf-jose-json-web-algorithms@tools.ietf.org
Subject: Re: [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Oct 2014 21:18:01 -0000

(Sooo many messages on JOSE, I'll work backwards and see how far
I get:-)

On 06/10/14 21:59, Jim Schaad wrote:
> 
> 
>> -----Original Message----- From: jose
>> [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones Sent:
>> Monday, October 06, 2014 12:54 AM To: Stephen Farrell; The IESG Cc:
>> jose-chairs@tools.ietf.org; jose@ietf.org;
>> draft-ietf-jose-json-web- algorithms@tools.ietf.org Subject: Re:
>> [jose] Stephen Farrell's Discuss on draft-ietf-jose-json-web- 
>> algorithms-33: (with DISCUSS and COMMENT)
>> 
>> Thanks for your review, Stephen.  I've included the working group
>> on the thread so they're aware of your comments.
>> 
>>> -----Original Message----- From: Stephen Farrell
>>> [mailto:stephen.farrell@cs.tcd.ie] Sent: Thursday, October 02,
>>> 2014 3:37 AM To: The IESG Cc: jose-chairs@tools.ietf.org;
>>> draft-ietf-jose-json-web- algorithms@tools.ietf.org Subject:
>>> Stephen Farrell's Discuss on
>>> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and
>>> COMMENT)
>>> 
>>> Stephen Farrell has entered the following ballot position for 
>>> draft-ietf-jose-json-web-algorithms-33: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to
>>> all email addresses included in the To and CC lines. (Feel free
>>> to cut this introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to 
>>> http://www.ietf.org/iesg/statement/discuss-criteria.html for more
>>> information about IESG DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found
>>> here: 
>>> http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
>>>
>>>
>>>
>>>
>>> 
----------------------------------------------------------------------
>>> DISCUSS: 
>>> ----------------------------------------------------------------------
>>>
>>>
>>>
>>> 
Sorry to pile on, but I guess such a detailed and broad piece of work
>>> is likely to attract many comments and discusses. Mine should be
>>> cleared up easily enough I hope.
>>> 
>>> (1) 6.3.2.7: Hmm, where was that discussed on the list?  I think
>>> it'd be better if >2 prime RSA was considered a separate
>>> algorithm. (I vaguely recall some IPR with such moduli for some
>>> uses too, but not sure.) I'd recommend dropping the whole "oth"
>>> parameter entirely. (I'll clear this discuss once its clear that
>>> this was discussed by the WG, I just want to check as I don't
>>> recall it.)
>> 
>> This was discussed in the thread "private keys, leading zeros"
>> initiated by James Manger on August 15, 2012.  (Sorry, I can't get
>> you the archive URL reference at present because I'm writing this
>> offline on an airplane over the Pacific.)  It was also discussed as
>> issue #153.  This feature was directly modelled on RFC 3447.
>> Applications are free to profile the JWK spec to prohibit the use
>> of such keys, so I don't see a compelling case to remove it.
> 
> Mike, I may be missing some messages in my archive, however the last
> message I see on this was you said that unless there was a demand for
> it you saw no need to include this.  It then got included.  Do you
> have a message I am missing?

Ah, ok, I'll leave this bit open for the present.

> 
>> 
>>> (2) Instructions to DEs: would registering DES be considered ok
>>> or not? What about myJustInventedPrivateAlg?  What about a
>>> request for 10 ccTLD specific Algs? I think these need a bit more
>>> clarity wrt cryptographic "goodness." As a nit, "makes sense"
>>> isn't going to help too much, we've seen that reasonable folks
>>> can differ on that here. Again I don't recall that discussion on
>>> the list, but please point me at it if it
>> happened.
>> 
>> Registering DES with the Implementation Requirements value
>> "Prohibited" would be permitted.  The instructions on the "JOSE
>> Implementation Requirements" registry field include: Any
>> identifiers registered for non-authenticated encryption algorithms 
>> or other algorithms that are otherwise unsuitable for direct use as
>> JWS or JWE algorithms must be registered as "Prohibited".
>> 
>> Note that this capability was added at the request of the W3C
>> WebCrypto WG. (WebCrypto is choosing to support some algorithms
>> that JOSE explicitly chose not to, including some non-authenticated
>> encryption algorithms.)  "Deprecated" is also a value available to
>> registrants and the DEs.
>> 
>> If you want to supply additional proposed language to the DEs, that
>> would be welcomed.
> 
> I would tend to say that registering algorithms that we know now are
> blah would not be acceptable.   (Note that you would need to create
> an AEAD version of DES but that is doable.)  However, I would say
> that registration of vanity algorithms would not necessarily be
> verboten.  I would hope that the DEs did some small due diligence
> that the algorithm has been analyzed and is not trivially bad.
> 
> It is not clear to me that it is possible to give language beyond "Do
> the right thing" that would be usable.

It is tricky yes. I'll clear that as a DISCUSS and make it a
comment.

S.

> 
>> 
>>> ----------------------------------------------------------------------
>>>
>>> 
COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>>
>>>
>>> 
Col 1 of the final 3 rows are unfortunate.
>> 
>> I don't know how to teach xml2rfc to not do what it did to the
>> final 3 rows, but I can make a note to have the RFC editor manually
>> address this if the tool can't.
> 
> Add a width attribute to the ttcol with either "digits" (for fixed
> width) or "digits%" (for percent width) to the column in question.
> 
>> 
>>> - Surprised there was no need for integer DH. Can be added later
>>> I guess.
>> 
>> No one has previously asked about it.  But there registry will be
>> there for it to be added, if wanted/needed.
> 
> Everybody is going EC these days.
> 
>> 
>>> - 6.2.1: Given that the point compression IPR is now expired 
>>> (right?) did the WG consider now allowing that? I wondered how
>>> much work it would be to add now, vs to add later. If "later"
>>> would cause a lot of duplication, then maybe "now" would actually
>>> be worth it. ("Later" might also be fine considering the current
>>> work in CFRG on additional curves.)
>> 
>> I recall that in the discussions, people were happier having a
>> single representation than multiple representations.  Given the
>> curve discussions, that's also another reason I'd opt for "later".
>> 
> 
> There was discussion on having compressed points.  Richard suggested
> it in his message to change how points were done.  Mike said that he
> wanted a single method and Russ said that the uncompressed method had
> to be mandatory.  The group kinda drifted into just having the
> uncompressed format.
> 
>>> - 6.3.1.1: allowing the extra 0x00 would be a better choice IMO,
>>> but
>> whatever.
>>> Those were historically added so that buggy decoders wouldn't
>>> wrongly think numbers negative, which could still happen maybe.
>> 
>> Yeah, I realize why the Java library does this.  This was another
>> case where we decided that having a single representation would
>> create less interop problems down the road than allowing multiple
>> representations.
> 
> They were also added for ASN.1 because these were positive numbers
> and not negative numbers.  This affects prefix removal for integers.
> Would not have been an issue if they had been octet strings.  I am
> agnostic about removal or keeping.  Knowing the length of the key by
> doing a simple strlen seems to me to be a win.
> 
>> 
>>> - 7.1, 2nd para: why not RSA2048 earlier then?
>> 
>> I don t actually recall.  I think the two choices reasonably
>> available to us at this point are to either keep or delete this
>> paragraph.  Which would you prefer?
> 
> 
> Might be better to say.  If multiple variations of an algorithms are
> being registered that vary only in key length (for example AES128 and
> AES256) and the key length needs to be fixed (for example because it
> will be created by a KDF), then....
> 
>> 
>>> - 8.3: Is 65537 considered a "low" e?  "Low" is too vague there.
>> 
>> No, it's not "low", but I can't back that up with a reference off
>> the top of my head.  Working group, what are the relevant documents
>> here that we could reference for this information?
> 
> Boneh, Dan (1999). "Twenty Years of attacks on the RSA Cryptosystem".
> Notices of the American Mathematical Society 46 (2): 203–213.
> 
>>> - 8.6: suggesting a CA as a cure for oversized keys is odd, I
>>> think those are separable things and e.g. TOFU might be just as
>>> or more effective then X.509 here.
>> 
>> Sean Turner suggested adding that text on July 6, 2012.  Proposed
>> edits would be welcomed.
> 
> Yeah, I tend to agree.  It might be better to just say that
> implementations should set an upper limit on the key sizes they
> accept and enforce it.
> 
>> 
>> -- Mike
>> 
>> _______________________________________________ jose mailing list 
>> jose@ietf.org https://www.ietf.org/mailman/listinfo/jose
>