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

[Paul Hoffman <[e-mail]>]

On Jan 7, 2015, at 4:20 PM, Richard Barnes <[e-mail]> 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