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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 08 January 2015 14:12 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B16241A6FFC; Thu, 8 Jan 2015 06:12:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7wy0s0euehM; Thu, 8 Jan 2015 06:12:24 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031751A1A58; Thu, 8 Jan 2015 06:11:41 -0800 (PST)
Received: by mail-lb0-f174.google.com with SMTP id 10so3144896lbg.5; Thu, 08 Jan 2015 06:11:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OlfmXORr3SR8IfCDzc7ui8FsXJ8hk0u3Z3oU4jGeY1A=; b=ZRSDGAZaCDK4OBUlPrDF9BqVqF0YVAi0FLg7qoRDsroRr+KY5rmJQbr8aep/+71YLv 9eRTlX4Iyw6Y9VxiFWgrjQke6M4V+r5myU9xtOMhR9rp9LU/SozakFChcmsJjudsZrYr uZduLswKQNKjqRTCZvI+ZNTwNzPjwDLw5iZZEVi8qZAnv76EpdUdlo12Sh6I8HV0dMFX ZPfhrK64e2f33HtrJhAq6IheABM7rfYhwuwKCcoacMPo0XH4pAsj8bavdrqHX1340+av qeZ/HcLjozRfL1PJoId2wuDALvCeY+nAirpObctgeIA612nOck618lYWRIb3tmyURi3A u09Q==
MIME-Version: 1.0
X-Received: by 10.112.52.229 with SMTP id w5mr13958219lbo.52.1420726299268; Thu, 08 Jan 2015 06:11:39 -0800 (PST)
Received: by 10.112.49.52 with HTTP; Thu, 8 Jan 2015 06:11:39 -0800 (PST)
In-Reply-To: <54AE7AA0.2000100@cs.tcd.ie>
References: <20150108002015.24345.3508.idtracker@ietfa.amsl.com> <CAEB21E0-EF1C-4F48-8434-1B85AEC3C113@vpnc.org> <54ADDC98.4000009@cs.tcd.ie> <CAL02cgTg4UJ80_032eEgjnBZ4OBLUwXReg50Vmi-A1eDHsLqAQ@mail.gmail.com> <54AE6DF2.80500@cs.tcd.ie> <CAL02cgQWBkkTutXUu102_B2eGkEhUb7UnqTdYt5-S8_==HWQFw@mail.gmail.com> <54AE7AA0.2000100@cs.tcd.ie>
Date: Thu, 08 Jan 2015 09:11:39 -0500
Message-ID: <CAHbuEH53BPseyizVBvUXK76dwVUPPpF6y4tUafrktA6YeE0V2Q@mail.gmail.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/yvMJZgjheFjTaGo9UiuS7XsKWxI>
Cc: "httpauth-chairs@tools.ietf.org" <httpauth-chairs@tools.ietf.org>, Richard Barnes <rlb@ipv.sx>, "draft-ietf-httpauth-hoba.all@tools.ietf.org" <draft-ietf-httpauth-hoba.all@tools.ietf.org>, Paul Hoffman <paul.hoffman@vpnc.org>, "http-auth@ietf.org" <http-auth@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [http-auth] Richard Barnes' Discuss on draft-ietf-httpauth-hoba-09: (with DISCUSS and COMMENT)
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Jan 2015 14:12:30 -0000

On Thu, Jan 8, 2015 at 7:40 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
> (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
>
> On 08/01/15 12:06, Richard Barnes wrote:
>> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> 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 <
>>> stephen.farrell@cs.tcd.ie>
>>>> 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 <rlb@ipv.sx> 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?
>
> 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."

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

>
> Happy to wordsmith that.
>
>
>>
>>
>>
>>>>>>> (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."
>
> 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.
>
>>
>>
>>
>>
>>>>>>> (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
>>>>>> http-auth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/http-auth
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>> On Thu, Jan 8, 2015 at 11:45 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
>> 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 <
>>> stephen.farrell@cs.tcd.ie>
>>>> 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 <rlb@ipv.sx> 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
>>>>>> http-auth@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/http-auth
>>>>>>
>>>>>
>>>>
>>>
>>



-- 

Best regards,
Kathleen