Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Thu, 08 January 2015 01:25 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AA61AC3D0; Wed, 7 Jan 2015 17:25:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 9peeK1Jcxp-2; Wed, 7 Jan 2015 17:25:48 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE771AC3CF; Wed, 7 Jan 2015 17:25:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id F15B2BED1; Thu, 8 Jan 2015 01:25:46 +0000 (GMT)
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 Q_QSGt8Fmknh; Thu, 8 Jan 2015 01:25:45 +0000 (GMT)
Received: from [10.87.48.73] (unknown [86.46.23.193]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2961EBEC0; Thu, 8 Jan 2015 01:25:45 +0000 (GMT)
Message-ID: <54ADDC98.4000009@cs.tcd.ie>
Date: Thu, 08 Jan 2015 01:25:44 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Hoffman <paul.hoffman@vpnc.org>, Richard Barnes <rlb@ipv.sx>
References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <CAEB21E0-EF1C-4F48-8434-1B85AEC3C113@vpnc.org>
In-Reply-To: <CAEB21E0-EF1C-4F48-8434-1B85AEC3C113@vpnc.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/http-auth/Cqb7phfzqEe88bz4FuPjX7eJ6Dg
Cc: draft-ietf-httpauth-hoba.all@tools.ietf.org, http-auth@ietf.org, httpauth-chairs@tools.ietf.org, The IESG <iesg@ietf.org>
Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 01:25:51 -0000

FWIW, I'm fine that Paul's recollection of the WG stuff is better
than mine and with his putting the pkcs#1 stuff in too.

S

On 08/01/15 01:19, Paul Hoffman wrote:
> On Jan 7, 2015, at 4:20 PM, Richard Barnes <rlb@ipv.sx> wrote:
>> (1) It does not seem to me that the mechanism defined in this document
>> actually conforms to the framework for HTTP authentication.  The general
>> framework defined in RFC 7235 is all scoped to a resource -- you can
>> implement authorization for a specific resource, without impacting
>> anything else on the server.  HOBA, by contrast, requires the
>> authenticating resource to be also be correlated to several resource
>> under .well-known, meaning that it will not be usable in a large number
>> of deployment circumstances.  Was this issue discussed in the WG, and was
>> there input from the broader HTTP community?
> 
> Yes and yes. (Stephen is wrong that it was not.) The "authenticating resource" in HOBA is purposely more expressive than that in RFC 7235, and thus takes more primitives than HTTP auth. There was plenty of WG discussion around this.
> 
> 
>> (2) What is your justification for using a SHA-1 based signature in a new
>> protocol, when it is being actively deprecated elsewhere, in particular
>> the web PKI?
> 
> RSA-SHA1 is widely implemented, and thus it seemed appropriate for a MAY-level definition when there is a more popular algorithm (RSA-SHA256) at MUST-level. Until RSA-SHA1 is a "MUST NOT" everywhere, there is no danger to having it here.
> 
>> (3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST
> 
> There is no interoperability mandate for particular RSA key lengths, so "SHOULD" is more appropriate here (until the IESG finally gets around to updating RFC 2119...).
> 
>> (4) Given that the size of the header seems to be a concern (since you're
>> not passing the key in the header), why are there no ECC signing
>> algorithms defined?  It seems like if you used any of the normal curves,
>> you could comfortably pass the key along with the authentication value.
> 
> Because there is not yet agreement on which ECC signing algorithms are likely to be popular in a year or two. We're watching the CFRG discussion, and it is not yet coming to consensus. When it does, this Experimental RFC can be updated.
> 
>> (5) For that matter, why bother defining a new algorithm registry at all,
>> when JWA provides a perfectly nice one that only costs you 4 characters.
> 
> We did not want to be tied to the JWA registry, given that JOSE could go in quite different directions.
> 
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> The HOBA-TBS construction seems really unnecessarily complicated.  Other
>> than in the "origin" component, there are no ":" characters allowed in
>> any of the components, so if you could remove the unnecessarily pretty
>> serialization of the origin, you could just use ':' as a delimiter.  Or
>> leave the origin, and delimit with something like %x20.  Either way, this
>> length construction seems like a pain to implement by comparison.
> 
> We started with a less complex construction, and the WG specifically asked for this.
> 
>> "alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces
>> unnecessarily.
> 
> It is also unwise to have more than 99 possible algorithms for signing.
> 
>> In addition to the funny title of Section 6.2.2, the contents seem kind
>> of risible as well.  Making a OTP is 100% equivalent to the mechanism
>> recommended in Section 6.2.3, and arguably more likely to deploy (since
>> the OTP doesn't have special semantics of being a URI).
> 
> There is wide disagreement on what is more likely to deploy. Also, I'm pretty sure Stephen is correct about your view on OTP here.
> 
>> Please update the algorithms so that the reader doesn't have to go look
>> up which algorithm this is (PKCS1 vs. PSS).
>>
>> OLD: "RSA is defined in Section 8.2 of [RFC3447]" 
>>
>> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of
>> [RFC3447]"
> 
> Sounds good; now fixed in the post-IESG version.
> 
>> Given how convoluted the use case is here, an example would be very
>> helpful.  At the very least to demonstrate the syntax of the
>> WWW-Authenticate header.
> 
> This doesn't seem all that needed, regardless of your view of convolution.
> 
> --Paul Hoffman
> _______________________________________________
> http-auth mailing list
> http-auth@ietf.org
> https://www.ietf.org/mailman/listinfo/http-auth
>