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

From: "Richard Barnes" <[email-masked]>
Date: Wed, 07 Jan 2015 16:20:15 -0800

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.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 01:01:29 +0000

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

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.

> protocol, when it is being actively deprecated elsewhere, in particular

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.

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

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

> 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

I felt no pain.

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

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.

> of risible as well.  

Thanks. Or not, I guess;-)

> Making a OTP is 100% equivalent to the mechanism

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.

> up which algorithm this is (PKCS1 vs. PSS).

Eh, no thanks:-)

> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of

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

Noted.

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jan 2015 17:19:18 -0800

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

> protocol, when it is being actively deprecated elsewhere, in particular

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

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

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

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

It is also unwise to have more than 99 possible algorithms for signing.

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

> NEW: "RSA indicates the RSASSA-PKCS1-v1_5 defined in Section 8.2 of

Sounds good; now fixed in the post-IESG version.

> helpful.  At the very least to demonstrate the syntax of the

This doesn't seem all that needed, regardless of your view of convolution.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 01:25:44 +0000

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:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Jan 2015 10:23:25 +0000

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 <[email-masked]>
wrote:

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

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

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

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

> in quite different directions.

Fair enough.  Cleared this one.

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 11:45:54 +0000

Hiya,

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

> authenticating resource has to be tied to the .well-known/hoba/register/

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.

> libary that fits within 64K and supports SHA-256 along with a bunch of

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.

> a 2048-bit key is roughly (choosing representative values after a few

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.

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

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

> Fair enough.  Cleared this one.

Cool.

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

---

From: Richard Barnes <[email-masked]>
Date: Thu, 8 Jan 2015 12:06:49 +0000

> that basis is not correct.

Isn't the burden on the one trying to weaken the protocol?  :)

All of the web development platforms I can think of have SHA-2 support.
Looking at the list on wikipedia:
http://en.wikipedia.org/wiki/Programming_languages_used_in_most_popular_websites

ASP.NET, C, C++, Java, JavaScript, Perl, Python, Ruby: Should be obvious
PHP, Xhp, Hack: http://php.net/manual/en/function.hash.php
Scala: https://github.com/Nycto/Hasher
Go: http://golang.org/pkg/crypto/sha256/
Erlang: http://erlang.org/doc/man/crypto.html
D: http://dlang.org/phobos/std_digest_sha.html

So unless you can come up with a platform that *doesn't* support SHA-2, I
don't see why it should be allowed.

In any event, it seems like this whole pageant is moot, since the document
*requires* SHA-2 support.  If you've got that, why would you ever do
SHA-1?

> for a stds track but not exp.)

Yeah, OK.  I guess I can live with this.  Could we possibly add some
bounding text, e.g.,

"Keys shorter than 2048 bits should only be used in cases where generating
2048-bit (or longer) keys is impractical, e.g., on constrained devices.  If
an application uses short keys, then it MUST expire and re-generate keys
periodically, say every few weeks."

> >>> We did not want to be tied to the JWA registry, given that JOSE could
> go
> >> in quite different directions.
> >>
> >

On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <[email-masked]>
wrote:

> >>> We did not want to be tied to the JWA registry, given that JOSE could
> go
> >> in quite different directions.
> >>
> >

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 12:40:00 +0000

(Richard and I plan to chat via IM before the call hopefully
so this is more to tee that up than to clear right now.)

There are a couple of changes below, those are done in the
working version at the usual [1,2].

   [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt
   [2]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt

> *requires* SHA-2 support.  If you've got that, why would you ever do

Because e.g. PHP4 is still installed on a site where I don't
get to fix that. Shodanhq indicates there are a number of those
still about, though less than I'd have expected, but not sure
if they search for that deliberately or as a side-effect.

But anyway, I have no problem saying rsa-sha1 MUST NOT be used
except in cases like that where you have no choice.

Given that the codepoint was in the draft for quite a while,
it seems silly (process-wonkery?:-) to take it out now and
then maybe re-use it for something else later, so I'd argue
we can leave the code point.

So I added:

"RSA-SHA1 MUST
NOT be used, except in cases where SHA256 is unavailable, say
if some developmemt platform has to be used that is quite out
of date."

Happy to wordsmith that.

> periodically, say every few weeks."

I've added the first sentence. I don't think the 2nd is wise
really but will explain in IM as its a bit convoluted. (And
of course, HOBA itself has no concept of expiry at all, that's
for the account handling code.)

Cheers,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 8 Jan 2015 09:11:39 -0500

> if some developmemt platform has to be used that is quite out

Thanks, I think this is a good change and in-line with what we've
asked on other drafts.  I don't think RSA-SHA1 should be needed and
would be good to deprecate it where possible.  You will just want to
fix the typo on "development".  I'm not sure why someone would want to
use a development platform that is really out-of-date though.  We
shouldn't encourage that as it presents additional risks, but this
text is an improvement...

-Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 14:15:35 +0000

On 08/01/15 14:11, Kathleen Moriarty wrote:
>  I'm not sure why someone would want to
> use a development platform that is really out-of-date though. 

Some web developers get no choice. They don't control the
web server, just their chunks of PHP code.

S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 8 Jan 2015 09:17:08 -0500

> web server, just their chunks of PHP code.

Sure, I get that, just don't think we should encourage it when we are
trying to deprecate old stuff.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 16:01:53 +0000

> so this is more to tee that up than to clear right now.)

So we did that. There're a few more tweaks in [1,2] and
Richard has cleared (thanks Richard).

If folks could check I didn't mess up with edits, that'd
be good,
Ta,
S.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Jan 2015 07:56:49 +0100

On 2015-01-08 02:01, Stephen Farrell wrote:
> ...
> ...

RFC 7235 is agnostic of cookies, it's a complete separate construct.

Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. 
If HOBA requires cookie support to make the HOBA HTTP authentication 
work (does it), it might make sense to say that clearly.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Fri, 9 Jan 2015 15:15:06 +0800

> Furthermore, cookies are entirely OPTIONAL in HTTP, at least in theory. If
> HOBA requires cookie support to make the HOBA HTTP authentication work (does
> it), it might make sense to say that clearly.

It doesn't, and I think it says *that* clearly.  That is, it says that
cookies can be used, and are typically used, but nowhere that they're
required.

Without cookies, I believe the client would have to re-send the
challenge-response with each request, until the challenge expires
(max-age), after which it would receive and handle a new challenge.
Cookies make things more convenient and save overhead.

Barry

---

From: Richard Barnes <[email-masked]>
Date: Fri, 9 Jan 2015 08:27:23 +0000

On Fri, Jan 9, 2015 at 6:56 AM, Julian Reschke <[email-masked]>
wrote:

> HOBA requires cookie support to make the HOBA HTTP authentication work
> (does it), it might make sense to say that clearly.
>
> Best regards, Julian
>

Julian,

Rather than cookies, my concern was that this authentication scheme isn't
scoped to the authenticating resource.  In addition to the authenticating
resource, the authentication process needs to have access to the resource
.well-known/hoba/register on the same host.  Does that cause you any
architectural concern?

I cleared because I felt like I could live with it for Experimental.  This
pattern would not fly with me for PS.

--Richard

---

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Jan 2015 09:43:45 +0100

On 2015-01-09 09:27, Richard Barnes wrote:
> ...
> Julian,
>
> Rather than cookies, my concern was that this authentication scheme
> isn't scoped to the authenticating resource.  In addition to the
> authenticating resource, the authentication process needs to have access
> to the resource .well-known/hoba/register on the same host.  Does that
> cause you any architectural concern?

It's workable unless the resource space is shared by multiple services, 
such as in Web application server.

> I cleared because I felt like I could live with it for Experimental.
> This pattern would not fly with me for PS.
> ...

I agree that it we'd want to think about a better approach.

Best regards, Julian