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

[Richard Barnes <[e-mail]>]

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

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

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?



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

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




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


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

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