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

[Richard Barnes <[e-mail]>]

Hey guys,

Thanks for responding productively to a DISCUSS that I admit was not
written very politely.  Sorry about that.

Couple of comments inline.

On Thu, Jan 8, 2015 at 1:25 AM, Stephen Farrell <[e-mail]>
wrote:

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

If you happen to have a pointer to that discussion, it would help me feel
more comfortable.

To be a little clearer about my concern, it seems like the fact that you
don't carry the public key in the Authorization header means that the
authenticating resource has to be tied to the .well-known/hoba/register/
resource.



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

But if you're REQUIRED to support RSA-SHA256, why would you ever use
RSA-SHA1?

Color me pretty skeptical that there are implementations that can't support
SHA-2 nowadays.  I just saw a presentation yesterday about an IoT crypto
libary that fits within 64K and supports SHA-256 along with a bunch of
other algorithms.



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

This is not about interop, it's about achieving an appropriate security
level.  That is another thing for which MUSTs are commonly used.

(If we're going to talk about 2119, the phrasing is "absolute requirement
of the specification", not "absolutely required for interop".)

To Stephen's point on JS performance: I made a little empirical test:
http://www.ipv.sx/tmp/rsa-2048.html

On a good laptop, a good phone, and a crappier phone, the time to generate
a 2048-bit key is roughly (choosing representative values after a few
clicks):
MacBook Pro: 5340ms
iPhone 6: 7192ms
FirefoxOS Flame: 31084ms

These values are not great, but they're within the range of asynchronous
operations that web pages already have to deal with, especially given that
keygen is a once-per-origin operation.  As far as sign() operations, the
worst case among these devices was ~500ms, which is again not terrible.



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

This is pretty weak sauce.  It's not like ECDSA with P-256 is going to go
away overnight when CFRG make up their minds.

Maybe I'm overly worried about the complexity here, but it seems like using
ECC could allow you to just shove the public key in the Authorization
header.  That would obviate the need for the registration resource,
resolving point 1 above, and generally make HOBA easier to implement.

Nonetheless, I moved this point to a COMMENT.


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

Fair enough.  Cleared this one.



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

Sure, but that seems like a process issue, not one to enshrine in syntax.



> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/http-auth
> >
>