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

[Stephen Farrell <[e-mail]>]

Hope this works ok - I've pasted in the comment text and my
responses to cut down the nesting.

A proto -10 version with changes indicated below is at [1] the
diff vs. -09 at [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

> This document would benefit from some section somewhere giving a
> set of clear, numbered steps, saying who sends, who receives, and
> who does what with what input at each step.  I will propose such
> text.

And I'll happily look at that when it's available. (And hope to
not have to wait much:-)

> Minor editorial nit: you use "a HOBA" fairly consistently, but "an
> HOBA" appears twice.  Oughta fix.

Fixed.

> The abstract appears to overstate the password issue.  It'd be
> better for the abstract to say that it eliminates the transmission
> of passwords and their storage on the server, which are really the
> points.

TBH, I prefer the current text a lot.

> The introduction might expand on that a little, noting
> that passwords might still be used in the user interfaces, but they
> would be exclusively client-side things, never transmitted and
> never seen by servers.

I'd be against adding such. IMO an implementation like that is not a
great idea as it's phishable (the user won't know that the password is
local only and will re-use the same password in more than one place).
That's a very strong (IMO) reason to argue that private key protection
is an OS/platform issue and ought not be a HOBA implementation issue.
And private key protection done without passwords is much more usable
and less phishable.

>
> -- Section 2 --
>
> The definition of "alg" says "the encoding of RSA-SHA256 is 0x30,"
> but the ABNF above says "alg = 1*2DIGIT", which implies "30", not
> "0x30".   As I look at Section 9.3, I think I see the problem and
> my confusion.  I don't think you want "a single octet" here
> (otherwise, how would you encode 12 or 99?  Don't you really want
> something like this?:
>
> OLD
>    o  alg: specifies the signature algorithm being used encoded as a
>       single octet as defined in Section 9.3.  RSA-SHA256 MUST be
>       supported, RSA-SHA1 MAY be supported.  The IANA registered
>       algorithm values are encoded as ASCII numbers; for example, the
>       encoding of RSA-SHA256 is 0x30.
> NEW
>    o  alg: specifies the signature algorithm being used.  RSA-SHA256
>       MUST be supported, RSA-SHA1 MAY be supported.  The IANA
>       registered algorithm values (see Section 9.3) are encoded as one-
>       or two-digit ASCII numbers.  For example, RSA-SHA256 (number
>       0) is encoded as the ASCII character "0" (0x30), while a future
>       algorithm registered as number 17 would be encoded as the
>       ASCII characters "17" (0x3137).
> END

Fixed.

>
> -- Section 3 --
>
> 	  The "realm" attribute MUST NOT appear more than once.
>
> Does that mean that "challenge" and max-age can appear more than
> once?

No.

> If not, why call it out for "realm" and not for the others?

I forget and haven't found a why. I think that was in response
to some other comment. Would prefer leave it just in case.

> It might be good if the description of "max-age" made it clear that
> it's for the purpose of allowing multiple uses (multiple sigs).  As
> it is, it looks like it's there to limit the delay before the
> challenge is answered (once).  Maybe just a forward ref to Section
> 8 is good enough here.

I looked at it again and still think it's ok as-is.
There is more discussion of max-age a couple of paras
below this bullet list.

>
> -- Section 4 --
>
> The second paragraph starts by saying that localStorage is
> required, and gives a reference.  It ends by saying that
> localStorage is not required, because IndexedDB works too, and it
> gives a reference.  That's not a disaster, but it's sloppy, and
> it'd be better to say it all up front.  It also makes me wonder
> whether the security considerations about attacks on localStorage
> do or don't also apply to IndexedDB.

Shuffled that about a bit. Better now.

> Another very minor point: I would avoid using "a hassle for users"
> in an international document that non-native speakers are expected
> to understand.  "Difficult for users" seems just as good and more
> understandable to all.

Fixed.

> Does the server really use session cookies to navigate around a
> site?  Or does the server give the client a session cookie for the
> client to use to navigate?

Fixed.

>
> -- Section 6.2 --
>
> It seems odd to put the NOT RECOMMENDED mechanism in the middle; I
> suggest switching sections 6.2.2 and 6.2.3.

Noted. Not done:-)

> -- Section 8 --
>
> The first paragraph doesn't say enough to make sense to me.
> Perhaps a few more words about why?

I swapped the 1st and 2nd paras. The 1st was a bit abrupt yes
but I think it fits better now.

>
> -- Section 8.3 --
>
> The chances that a typical user (consider my mother) will know or
> care about this, much less will "request" anything is vanishingly
> small.  Can you say anything here about what can be done that would
> have any practical utility?

I think we covered this sufficiently. I do not want to
get into recommending ways HOBA implementers can do what
really ought be an OS/platform function. In the end I
added that specific point and did tweak a bit though.

>
> -- Section 9.3 --
>
>    Please create a new HOBA signature algorithms registry as follows,
>    with the specification required rule for updates.  New HOBA signature
>    algorithms SHOULD be in use with other IETF standards track protocols
>    before being added to this registry.
>
> I don't think the SHOULD is really right -- who is the target?
> This needs to be cast as instructions to the designated expert,
> perhaps as, "The designated expert will review other uses of
> requested new HOBA signature algorithms, with particular
> consideration to their use in other IETF standards track
> protocols." Perhaps there's also another word or two to say about
> what the DE should consider?

I really think the SHOULD here is good enough and is
what we want and no more guidance for a qualified DE
is needed and I think we agreed that that's ok.

>
> -- Sections 9.4 and 9.5 --
>
> Might there be any advice for the designated expert, anything at
> all?

No, I think it's fine - there is no equivalent to the
sig alg thing in 9.3 needed.

Cheers,
S.