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

[Stephen Farrell <[e-mail]>]

Hi Richard,

You are taking into account that this is aiming at experimental right?
I get the feeling you're not, but anyway...

On 08/01/15 00:20, Richard Barnes wrote:
> 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.  

"does not seem" is very imprecise please say exactly how if you
are going to maintain this as a blocking point

> The general
> framework defined in RFC 7235 is all scoped to a resource -- you can
> implement authorization for a specific resource, 

That works for HOBA too, just fine.

> without impacting
> anything else on the server.  

Where is that stated? Wouldn't that mean that using cookies after
an HTTP auth somehow didn't conform? Wouldn't that be nonsense?
(And possibly indicate an issue with 7235 but not HOBA.)

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

s/large number/some/ or do you have evidence of magnitude?

And I'd note that all web and HTTP authentication/authorization
enhancements are likely to have similar issues, e.g. oauth can't
be used everywhere. And that's just fine.

> Was this issue discussed in the WG, and was
> there input from the broader HTTP community?  

That was not discussed in the WG. The broader HTTP community were
invited to comment a number of times and did not raise this or
basically did not comment, with a couple of exceptions where folks
did take the time. However, that issue (lack of interest from the
HTTP community and esp. browsers) was IMO disposed of when the WG
was chartered so ought not by itself be a valid argument against
this work or any other work from this WG as I'm sure you'll agree.

Yes, HOBA uses .well-known, but that does not mean it is not
conformant to 7235. Please quote me something in 7235 that indicates
otherwise.

Yes, there will be web sites where you cannot use this. That's just
fine.

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

SHA256 is the MTI here. SHA1 is a MAY. I'd be fine with losing SHA1 if
you go check and tell me that there are finally no development
environments that only have SHA1 and not SHA256. That could be the case
now but wasn't when we started this. (I think it was PHP didn't have
it initially, but that I know is ok now.) In any case, allocating an
optional to use codepoint should be fine.

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

There are still some non-WebCrypto cases where 2048 (keygen in
particular) is too slow in JS for that to be a good plan. Making that
a MUST here and now would be a mistake. When/if WebCrypto is fully
deployed that might well change but it's too early for that still
I think.

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

RSA is an acceptable choice from the security POV.

One reason there is no ECC as I still think the IPR situation isn't
as clear as for RSA. I'd expect that to change if this ever gets
put on the standards track but I think insisting on that wouldn't
be correct. Being conservative in that way wrt IPR should not be
penalised.

And I think ECC would also suffer from the same as SHA256 but much
worse, as I don't think all development environments support ECDSA
yet.

I'd also prefer to wait for CFRG to produce an ECC signing scheme
with non-NIST curves and without needing a random input before I'd
want to make ECC the MTI thing. That could well happen but we're not
there yet.

Arguably, ECDSA would be worse than RSA with non-WebCrypto JS code
as a dodgy RNG exposes the private key. That will I hope be fixed
in a new ECC signature scheme from CFRG but that doesn't yet exist.

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

Is that DISCUSS-worthy? Building dependencies like that is just a
design choice. It is one that could be revisited later maybe by a
WG but not (I think) in IESG eval. In any case, this work was done
in parallel with JOSE and such cross dependencies are a recipe
for disaster:-)

Again, if a standards track version were to be desirable that
could easily be changed then.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The HOBA-TBS construction seems really unnecessarily complicated.  

It's not complicated IMO, not when compared to alternatives. But
whatever, that kind of subjective comment isn't resolvable.

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

I felt no pain.

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

For algs, I'd prefer just two bits myself actually. 330+ ciphersuites
in TLS is bad really. I don't expect this to be any deal anyway, 99
signature algs is more than enough so far.

> 
> In addition to the funny title of Section 6.2.2, the contents seem kind
> of risible as well.  

Thanks. Or not, I guess;-)

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

No. A human-memorable OTP is not at all the same as 6.2.3. You are
simply incorrect there sorry. With a human-memorable OTP and a server
with any significant traffic guessing an OTP would get the attacker
some value even if they don't know whose account they are joining.
And preventing that is hard or worse, since the the attacker can
trickle the guesses.

With 6.2.3, the URL can and should not be human memorable and hence
guesses won't be an issue with any sensible implementation.

Again, you are just wrong there, but perhaps not risibly so.

> 
> Please update the algorithms so that the reader doesn't have to go look
> up which algorithm this is (PKCS1 vs. PSS).

Eh, no thanks:-)

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

I don't really find those decorated names useful to be honest.

> Given how convoluted 

Thanks for the pejorative.

> the use case is here, an example would be very
> helpful.  At the very least to demonstrate the syntax of the
> WWW-Authenticate header.

Noted.

S.


> 
>