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

[Stephen Farrell <[e-mail]>]

Hiya,

On 08/01/15 10:23, Richard Barnes wrote:
> Hey guys,
> 
> Thanks for responding productively to a DISCUSS that I admit was not
> written very politely.  Sorry about that.

I do it myself from time to time, no probs. (And to be honest I
was more rude about your ballot in IM to someone else, so we're
even:-)

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

Yes, that's true. But entirely acceptable as a reasonable
limitation of the scheme. It's reasonable because a) less
header bloat if you send public key once, b) with RSA in
particular public keys are big, and c) I hold out the hope
that I can someday develop a privacy friendly kid type so
that the strongly identifying nature of the HOBA signature
is addressed. (I have not so far figured one out, sadly.)

So I still don't see a reason for this to block the experiment.

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

That was the case with PHP when this work started and at that time I
needed the rsa-sha1 code point for my code. That was only a year or
two ago. I bet there are still web sites with only that version of
PHP available today - that is scary but adding HOBA to such could
still represent a security improvement if it meant that a new
application can be deployed without a new password verifier DB, and
that would be the case since we have the rsa-sha1 codepoint. Taking
away the codepoint would prevent such being deployed. And we know
for sure that the relevant risk here is not the signature crypto
but is overwhelmingly and utterly the password verifier DB. You are
I fear arguing that we ought prioritise crypto plumbing over the
real security risk.

I have not done a survey of all web development platforms to check
if this is now a solved issue or not. You skepticism is fine (and
perhaps correct) but if you don't do that survey, then blocking on
that basis is not correct.

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

I've seen it take >120s which is not usable in this context. That
was on older iphones (4 I think) with various browsers. With some
older versions of IE on older laptops it's also horrendous.

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

Signing is tolerable in most cases thanks to the getchal and using
a worker.

And the appropriate security level for HOBA is not the usual thing
actually. Here we're after "substantially better than passwords"
and will likely transition to a cookie (bearer token) just after
signing. So I would argue that even an otherwise-undesirable 1500
bit modulus could be ok here, if a site has a way to bump that up
later, e.g. as new browsers deploy webcrypto. However, that is not
stuff that needs or ought be in the RFC.

For an experimental RFC we should not block on this. (I would myself
for a stds track but not exp.)

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

The development platform issue that perhaps no longer exists for
sha256 is I believe still real for ecdsa.

But the main thing I'd like from the CFRG work would be to lose the
RNG requirement at signing time, which is unnecessarily a part of
ECDSA. That's a real security win, if we get it.

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

Cool.

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

The opposite I think. We seem unable to fix the vanity/national crypto
thing via process so I'd like to see us try via syntax myself. But
that's for another day:-)

Cheers,
S.

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