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

["Richard Barnes" <[e-mail]>]

Richard Barnes has entered the following ballot position for
draft-ietf-httpauth-hoba-09: 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-httpauth-hoba/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

(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?  

(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?

(3) "RSA modulus lengths of at least 2048 bits SHOULD be used." -> MUST

(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.

(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.


----------------------------------------------------------------------
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.

"alg = 1*2DIGIT" - In general, it seems unwise to limit code point spaces
unnecessarily.

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).

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]"

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.