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

From: "Barry Leiba" <[email-masked]>
Date: Mon, 05 Jan 2015 09:48:55 -0800

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

Point 1:
I find the document to be really unclear about who does what with which
and to whom and....  I gather that what happens is that the challenge is
sent as part of the www-authenticate header, and that the client sends a
HOBA-RES back to the server in an authorization header.  I don't see the
point of the HOBA-TBS at all: it looks like it's that the "sig" in the
HOBA-RES is a signed version of the HOBA-TBS, but I don't see anything
that says that clearly.

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 don't find Section 5 to be doing that at
all.  "the client authenticates by signing a blob of information as
described in the previous sections," still leaves me wondering what blob
was signed, and sent how. And yes, I see that "blob" is used elsewhere,
but it's not a technical term.

Some other, easier-to-deal-with things for discussion, some of which
might just involve small clarifications (or an explanation to me that
results in my slapping my own forehead):

-- Section 2 --

In the ABNF for HOBA-TBS, is something supposed to be between the
elements?  If not, how do I know when the base64 value for nonce ends and
the length value for alg begins?

-- Section 6.3 --

   The server SHOULD also revoke or delete any cookies associated with
   the session.

Why is that not MUST?  How good is a "logout" if stolen cookies from that
session can still be reused?

-- Section 6.4 --

Protocol: does asking for and getting a new challenge affect the session
state?  The document should be clear about what happens, rather than just
saying that the client can ask for a new challenge.  Is it like a logout
and re-login?  Or what?

-- Section 8.2 --

I don't think you need to say "a la LinkedIn," and I think it's a bad
idea to have us link a company's name to a password compromise forever in
an RFC.  Especially when it's not necessary.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

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

Note that the rest of these notes were entered as I read the document
from top to bottom.  That means that some things got explained later, and
that leads to the DISCUSS point about the document's organization and
having a clear step-by-step run-through.

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

For "realm", I can't really make sense of "Recall both sides know when
this needs to be there independent of the encoding via a zero length." 
Can you rephrase and/or repunctuate this (probably without the word
"recall")?

For "challenge", I'm not completely sure what the SHOULD part of this is
meaning to say:

      The challenge MUST be chosen
      so that it is infeasible to guess, and SHOULD be indistinguishable
      from (the base64url encoding of) an at least 128-bit long random
      string.

My guess is that you're saying that, say, "frxM7jEplDq" meets the SHOULD,
while "eat my shorts" doesn't (extend to 128 bits in your mind).  I get
that, but it's dicey, random-wise, because it implies that "eat my
shorts" can't come up randomly, and (here's the really dicey part) I
should refuse to use it if it does.  I wouldn't worry about this but for
the SHOULD; with the SHOULD, I'm not sure how I can be sure that I comply
with it.

This section is really unclear about who does what with which and to whom
and....  I gather that what happens is that the challenge is sent as part
of the www-authenticate header, and that the client sends a HOBA-RES back
to the server in an authorization header.  I don't see the point of the
HOBA-TBS at all. Perhaps it's that the "sig" in the HOBA-RES is a signed
version of the HOBA-TBS, but I don't see anything that says that,
anywhere.

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 don't find Section 5 to be doing that at
all.  "the client authenticates by signing a blob of information as
described in the previous sections," still leaves me wondering what blob
was signed, and sent how. And yes, I see that "blob" is used elsewhere,
but it's not a technical term.

-- Section 3 --

      The "realm" attribute MUST NOT appear more than once.

Does that mean that "challenge" and max-age can appear more than once? 
If not, why call it out for "realm" and not for the others?

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.

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

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.

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?

-- Section 5.3 --

How Does the server "recognize the CPK"?  I can't find anything that
tells me how the kid relates to the CPK.  I also don't see how the server
gets the CPK in the first place.  I realize that setting up the user's
account isn't part of HOBA, but the setup requirements need to be
explained, and I don't think they are.  The organization is also very
odd, only talking about "joining" the user after it talks about
validating the sig.

-- Section 6 --

Oh, no wait: the joining is part of the standard.  And the subsections
here answer the question I asked in 5.3 about how the CPK gets set up. 
Gaaaaa!  PLEASE reorganise this document!

-- Section 6.1 --

Why are the fields here not REQUIRED and OPTIONAL, using 2119 words, as
is the case in Section 3?

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

-- Section 8 --

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

   The administrator will most likely
   want to set the max-age to something that is not too slow on the
   slowest signing device that is significant for that site.

Maybe you mean "not too short"?

-- Section 8.2 --

As to the "counter-intuitive" part, see my earlier comment about what the
introduction says about not using passwords.

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

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

-- Sections 9.4 and 9.5 --
Surely, IANA (or the designated expert) will want to have some idea of
how high "small" might reasonably get.  Can you put any bound on it, even
a non-binding one?  And might there be any other advice for the
designated expert, anything at all?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 05 Jan 2015 19:45:11 +0000

Hi Barry,

(I'm sure it's obvious, but this is me-as-author responding...)

On 05/01/15 17:48, Barry Leiba wrote:
> and to whom and....  

That's very odd. We've had a bunch of reviews and an independent
implementation (I've not done an interop though) and you're the
first to make such a comment I think. The draft assumes familiarity
with the HTTP authentication framework (RFC7235) for sure and
(100% correctly I'd say) doesn't repeat any of that as any implementer
really has to know that before they start. That's stated in the
abstract and the very first sentence of section 1 so I'm very unclear
what else is needed. And given that the responsible AD for RFC7235
was one Barry Leiba, I'm very very puzzled as to how this is not
clear to you.

> I gather that what happens is that the challenge is
> HOBA-RES back to the server in an authorization header.  

That's all as per 7235.

> I don't see the

Section 2:

  "On receipt of a challenge (and optional realm) from a server, the
   client marshals an HOBA to-be-signed (TBS) blob that includes a
   client generated nonce, the web-origin, the realm, an identifier for
   the CPK and the challenge string; and signs that blob with the
   private key corresponding to the CPK for that web-origin."

I don't see what is not clear there sorry.

> with what input at each step.  

That's in RFC 7235.

> I don't find Section 5 to be doing that at

See above.

> results in my slapping my own forehead):

Hopefully, your forehead is already shiny:-)

> the length value for alg begins?

The previous len field tells you.

> session can still be reused?

The issue is that that function (revoke cookie) might not be available
to the HOBA code, or it might, depending on the kind of HTTP server
implementation.

> saying that the client can ask for a new challenge.  Is it like a logout

No there's no effect on any other state I think. The point of this
is just to get a fresh challenge if the one you had has expired or
whatever.

> an RFC.  Especially when it's not necessary.

Is that really DISCUSS worthy? I don't think it is. Which of
the DISCUSS criteria relate to that. Seems like a stylistic
thing to me.

Will check. But RFC editor would fix I'm sure. I'll fix if a -10 is
needed now.

> client-side things, never transmitted and never seen by servers.

I'll take that under advisement.

> encode 12 or 99?  Don't you really want something like this?:

Yep, I think you're right there.

>       ASCII characters "17" (0x3137).

Wilko. I have that in my editor copy.

> Can you rephrase and/or repunctuate this (probably without the word

Sorry what's not clear?

>       from (the base64url encoding of) an at least 128-bit long random

The challenge might be shorter, or might be encoded in some other
way e.g. double encoding or something. All are reasonable, none
affect interop but we wanted to get the "at least" in there.

> version of the HOBA-TBS, but I don't see anything that says that,

See RFC7235.

> but it's not a technical term.

See RFC7235.

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

I forget TBH. I think it may be some buggy stuff seen with Basic
or Digest in the past. Or it might have been me keeping Julian as
happy as I could;-)

> (once).  Maybe just a forward ref to Section 8 is good enough here.

I think it's clear to be honest.

> localStorage do or don't also apply to IndexedDB.

I'll take a look again - localStorage is needed if you do not have
WebCrypto. IndexedDB is needed if you do have WebCrypto.

> does the server give the client a session cookie for the client to use to

I think it's clearer as-is to be honest.

> tells me how the kid relates to the CPK.  

It's not clear how a key identifier (kid) relates to a client public
key? (CPK) Really? A kid identifies the CPK in the nominal case. This
is crypto 101 though and ought not be there unless there's a specific
ambiguity which I don't think is the case.

> I also don't see how the server

I don't believe anyone else has had that problem. And explaining the
HTTP mechanism first seems appropriate here as that is the core thing.

> Gaaaaa!  PLEASE reorganise this document!

Even though nobody else has had that problem?

> is the case in Section 3?

Sorry I don't see a problem.

> suggest switching sections 6.2.2 and 6.2.3.

I'm fine with it as-is to be honest.

> few more words about why?

Will look at it.

> Maybe you mean "not too short"?

Nope. If signing took 2 seconds a 1 second max-age would be a problem.
And that can happen with very old JS engines. Will go away over time
and is nearly gone now. (Much moreso than when -00 of this was done.)

> introduction says about not using passwords.

I don't get what you mean to be honest.

> you say anything here about what can be done that would have any

This text is for a developer, not a user. And I have been asked
about this feature a number of times by people who don't get the
not-that-hidden complexities.

> two to say about what the DE should consider?

Sorry I don't get what's unclear. The SHOULD is targetted at the DE.
The text you suggest(?) in quotes would be less clear I think.

> designated expert, anything at all?

Really? Are we seriously worried about there being a bazillion
key id algs or device id types in an experimental RFC? I am not.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 03:01:19 +0000

On 06/01/15 01:26, Barry Leiba wrote:
> (Temporarily responding from my huawei.com address, as China blocks
> gmail.)

No probs, I'm sure we'll sort this and the gfw delays won't be that
much of a deal.

> 
>>> Point 1: I find the document to be really unclear about who does
>>> what with which and to whom and....
>> 
>> first to make such a comment I think. The draft assumes
>> familiarity with the HTTP authentication framework (RFC7235) for
>> sure and (100% correctly I'd say) doesn't repeat any of that as any
>> implementer really has to know that before they start. That's
>> stated in the abstract and the very first sentence of section 1 so
>> I'm very unclear what else is needed. And given that the
>> responsible AD for RFC7235 was one Barry Leiba, I'm very very
>> puzzled as to how this is not clear to you.
> 
> I'll take that last sentence as less snarky than it sounds, 

Not snark, but genuine puzzlement. From my POV you're asking for
this document to include crypto101 stuff. Yet we deal with far
more complex protocols that use the same (or more complex)
constructs all the time without requiring any of that.

And wrt the step-by-step stuff there's even a properly referenced
framework document that you brought to the IESG only months ago
that sets out exactly what your're asking be repeated here (or
else 7235 is broken).

I just do not get it. Maybe it's hard to be so puzzled without
sounding snarky, but I genuinely don't think we have a problem
here as I just can't really grok that you'd be asking for these
kinds of change in an experimental RFC and that those would
really be blocking.

> and I'll
> point out that I'm not reviewing this based on what Barry Leiba
> personally knows and understands, but on whether people reading the
> spec can understand it.

But it's been independently implemented by the portugal telecom
folks without them ever asking (me anyway) a single question.
And reviewed by multiple folks so I honestly think you may be
the exception here. And see above wrt puzzlement;-)

> Let's also keep in mind that people implementing this sort of thing
> will have more or less expertise in the HTTP authentication
> framework, and the document needs to be understandable to those who
> are less expert.  

101 != expert. foo-TBS being the signature input really is 101.

> Also also remember that we're hoping to get
> implementations of this out there, and we're skeptical that it'll
> happen.  Anything that makes it easier helps that cause. 

I don't accept that logic (though it's an aside), that'd call
for explaining RSA for example, which would be just as wrong
(IMO) as re-capitulating 7235 content. (Do you think it would
be a good plan for every http-auth WG doc to do that btw? Will
you post a DISCUSS position on all of those on that basis?
That's not something for HOBA, but maybe worth a ponder.)

> For all
> that, I think more explanation is important.

Clearly. And I think attempt to regurgitate text from a properly
referenced framework RFC in this one (and possibly others) would be
an error.

> 
> Despite what I know, I really did find myself tripping over things
> because there's no overall description of the flow, including things
> that are unique to HOBA (such as the HOBA-TBS, and the joining
> protocol).

For anyone who has implemented any signature based anything HOBA-TBS
is utterly obvious and far from unique. There'a >30 year heritage of
protocol constructs like that going back (to my knowledge, but I'm
sure further) to the 1984 X.400 blue-book which had a couple of pages
of text that became the 1988 X.509 that eventually became RFC 5280.
The joining protocol is just a simple signed assertion entirely
analagous to a PKCS#10 structure (so not quite 30 years old, maybe
20+:-).

In my local cache of RFCs (7376 being the hightest numbered) I see
69 RFCs that contain the case-insensitive string TBS btw.

Really, there is nothing new here. (And deliberately so, for any
new feature that even smelled remotely of novelty I went and tried
to find a >20 year old reference.)

An implementer who is not aware of that heritage will also not have
a problem, or else will have far far worse problems. The younger but
not dim implementer will just use openssl or some library that
handles this stuff more or less well or badly for the programmer and
will find that the text here matches the kinds of example one finds
on stackexchange etc fairly closely (since that's where I got my
PHP and JS code snippets while coding this and writing this text).

Honestly, I'm just genuinely puzzled a lot that any of this is
seen as worth asking never mind DISCUSS-worthy. (Could it be that
HOBA doesn't have enough complexity and is therefore more
amenable to such commentary, say compared to RELOAD which is
much more complex cryptographically? Well, if so, I guess that's
a good thing in a way:-)

>> client generated nonce, the web-origin, the realm, an identifier
>> for the CPK and the challenge string; and signs that blob with the 
> There's nothing that I see that explicitly makes that the "sig" item
> in the HOBA-RES.

See above wrt puzzlement. You're really missing that the output of
the "signs" operation is the sig value?

>>> 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.
>> 
>> That's in RFC 7235.
> 
> And should be in here, as well, to make it clear how the details of
> HOBA fit into the framework.

Fully disagree. And the author of 7235 who did review this did not
suggest that iirc. This should and does correctly require that the
implementer has read or is otherwise familiar with 7235. (What you
want would also call for every http-auth WG output to include that
kind of regurgitation. It's just a bad idea.)

> 
> I don't think this is a big deal, and I will
> 
> 1. move this to a non-blocking comment, and
> 
> 2. suggest text for you to include.

Fair enough. Absent that being better text, I'll likely argue to
not change. But I know you might produce better text so we'll see:-)

> 
>>> In the ABNF for HOBA-TBS, is something supposed to be between
>>> the elements?  If not, how do I know when the base64 value for
>>> nonce ends and the length value for alg begins?
>> 
> DOH! Yeh, of course.  Sorry.
> 
>>> -- Section 6.3 --
>>> 
>>> The server SHOULD also revoke or delete any cookies associated
>>> with the session.
>>> 
>>> Why is that not MUST?  How good is a "logout" if stolen cookies
>>> from that session can still be reused?
>> 
>> The issue is that that function (revoke cookie) might not be
>> available to the HOBA code, or it might, depending on the kind of
>> HTTP server implementation.
> 
> This is something we often struggle with, but I think it's a bad idea
> to soften the way we want a protocol to work because we know it will
> be difficult for some implementations.  We should use MUST or SHOULD
> based on what's right, and accept that even MUST will not be complied
> with if an implementation can't comply.
> 
> Do we really want this to be a MUST?  Perhaps we can waffle slightly
> by saying "MUST ... if it is possible to do so in the relevant HTTP
> server," or some such?

The way I look at this is in the spirit of the just issued RFC 7435.
We have little enough chance of this working so we ought (esp at the
experimental RFC stage) lean over to make deployment easier and not
harder.

So I do think SHOULD is right there tbh.

> 
>>> -- Section 6.4 --
>>> 
>>> Protocol: does asking for and getting a new challenge affect the
>>> session state?  The document should be clear about what happens,
>>> rather than just saying that the client can ask for a new
>>> challenge.  Is it like a logout and re-login?  Or what?
>> 
> OK; discussion has been had on this item.
> 
> Would it be worth adding a few words to say that (and to say that the
> session state doesn't change)?

That could be worse than now. Since a lot of the client code here will
be async code (XHR now and promises soon) we don't actually know that
that'll be the case. Other stuff might be going on as one branch of
code is refreshing the challenge.

> 
>>> -- Section 8.2 --
>>> 
>>> I don't think you need to say "a la LinkedIn," and I think it's a
>>> bad idea to have us link a company's name to a password
>>> compromise forever in an RFC.  Especially when it's not
>>> necessary.
>> 
>> Is that really DISCUSS worthy? I don't think it is. Which of the
>> DISCUSS criteria relate to that. Seems like a stylistic thing to
>> me.
> 
> I think it is: I think it's a very bad thing to disparage specific
> companies in our RFCs.

Its a statement of fact though. That is very different.

> That said, if you'd actually discuss 

Rhetorical fail alert:-) That last use of "discuss" != DISCUSS-worthy.
You're ignoring a) that this is a style issue and explicitly not
DISCUSS-worthy and b) that I am in fact happy to discus your
non-blocking comments.

I think it's entirely fair to establish if a point does or does not
warrant being blocking before disposing of the detail. (And hey,
when did an author not want to demote a DISCUSS to a COMMENT if that
is fair-game? Not often.:-)

> this with me (why you think it's
> important to leave it there), then the discussion will have happened,
> and we can move ahead.

Facts are much more convincing than abstractions. We could risk a
Streisand effect by not naming one of the major breaches of this
kind. That one was the most topical at the time that text was first
written. A naive reader following up on that will find a plethora
of other examples, of real associated costs and of lessons learned
none of which would be anywhere near as easily found starting (as
a naive reader) from an example.com abstraction (at least afaik
example.com have not had a significant password breach so far,
maybe we ought engineer one:-).

That enough?

>>> For "realm", I can't really make sense of "Recall both sides know
>>> when this needs to be there independent of the encoding via a
>>> zero length." Can you rephrase and/or repunctuate this (probably
>>> without the word "recall")?
>> 
>> Sorry what's not clear?
> 
> Sorry, I think I said very clearly what's not clear: I can't make
> sense of the sentence.  Can you try rephrasing it so maybe I can?

Can I bring you a rock? I'm sure you see my problem as well as
yours. Yes I can re-phrase of course, but I'm convinced that will
not be any sort of real improvement at all, e.g.:

  "Both sides know when realm is present or missing. Don't be
   mislead by the zero length encoding required."

I think that's worse and not deliberately so. (I admit to not
being terribly motivated to disimprove the text or do a
sideways-move edit though:-)

>>> 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 know you do; you wrote it.  Might you consider other input?  In the
> end, all I've asked for is a forward ref to Section 8.

This draft is at version -09 now. I think >50% of those revisions
were solely due to reviewer input. I resent the implication that I
and my co-authors are not open to input. (Not much mind you, but a
little:-) I fully accept that I'm impatient with some comments.

Yes, your ask is small. But is it a real improvement?

>>> 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?
>> 
> I don't and I think it's wrong.

Fair enough.

> 
>>> -- Section 6.1 --
>>> 
>>> Why are the fields here not REQUIRED and OPTIONAL, using 2119
>>> words, as is the case in Section 3?
>> 
> It's not a problem, it's a question.  Is there a reason you're using
> 2119 words in Section 3, and not here?

I honestly don't recall. At a guess, I would avoid 2119 terms where
possible as they generate pedantic commentary from folks who have
a different attitude than I towards 2119, cf. the Pete/Stephen WG
chairs lunch show from a couple of years ago:-)

But the honest answer again is: I don't recall and don't think it
matters.

And if there's not a problem, then maybe that's just dandy?

> 
>>> -- 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.
>> 
> At this point, it seems to me that you're just refusing to make
> changes because you want to refuse to make changes.  Whatever: this
> is non-blocking.

No, I'm pushing back on what I really see as a frankly odd
comment. Your comment to me is like asking that we ensure that
other things being equal we order the sections alphanumerically
by title.

> 
>>> The administrator will most likely want to set the max-age to
>>> something that is not too slow on the slowest signing device that
>>> is significant for that site.
>>> 
>> Nope. If signing took 2 seconds a 1 second max-age would be a
>> problem. And that can happen with very old JS engines. Will go away
>> over time and is nearly gone now. (Much moreso than when -00 of
>> this was done.)
> 
> I think you miss my (very minor) point: max-age is a time period, and
> is not something that's slow or fast; it's short or long.  So I'd say
> "not too short for the slowest signing device".  But, again, very
> minor, so it doesn't really matter.

Yep. Your text is 0.0001% better. (Precisely:-) I made the
change in my working copy.

> 
>>> -- 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?
>> 
> But the text talks about users requesting things, and I don't think
> users will understand any of this and request anything. 

Users will not read this RFC so that is just fine.

Yes it talks about, but is not for, users. It is just fine to
have this sentence talk about a cucumber even if no cucumber
will ever understand this sentence.

> Developers
> should be making it work for general users.  Is there anything they
> can do there?  If not, well, then not.  I'm asking.

My opinion of this is that that ought be an OS feature and
not an HTTP auth feature. That doesn't mean that will happen
of course. And I don't think we need this (again experimental!)
RFC to go into all that.

> 
>>> -- 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?
>> 
>> Sorry I don't get what's unclear. The SHOULD is targetted at the
>> DE. The text you suggest(?) in quotes would be less clear I think.
> 
> SHOULD is for describing protocol interoperability issues, not for
> giving instructions to DEs. 

Why? Where's it say that? I think a DE is quite capable of getting
the ask here.

> But maybe we'll see if Pete has an
> opinion here.

OMG, that too! :-)

Sure.

> 
>>> -- Sections 9.4 and 9.5 -- Surely, IANA (or the designated
>>> expert) will want to have some idea of how high "small" might
>>> reasonably get.  Can you put any bound on it, even a non-binding
>>> one?  And might there be any other advice for the designated
>>> expert, anything at all?
>> 
>> Really? Are we seriously worried about there being a bazillion key
>> id algs or device id types in an experimental RFC? I am not.
> 
> I'm not either; 

Cool then we can move on.

> it's just that IANA usually wants boundaries.  In any
> case, what about the second question: is there any guidance to be
> give to the DE here, or does the DE get to do whatever she likes?

Sure. As long as its small:-)

Cheers,
S.

> Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jan 2015 11:36:10 +0800

(For now, at least, I've gotten access to gmail through company
gateways.  We'll see...  Adding my huawei.com address in again, just
in case.)

> Not snark, but genuine puzzlement.

Ack; thanks.

> that sets out exactly what your're asking be repeated here (or

No, but there are bits that are unique to HOBA, and I want to make
sure that it's very clear how it all fits.

> the exception here. And see above wrt puzzlement;-)

Ack.  It's certainly possible that I'm being too picky; it's happened before.

> not change. But I know you might produce better text so we'll see:-)

OK.  BTW, I already changed my ballot, and I'll change it again to
reflect this exchange.  I'm not having it re-send email, because I
don't want to fragment the discussion into separate threads.  But you
can see the change in the tracker.

> So I do think SHOULD is right there tbh.

OK; removing that item as well now; thanks.

> code is refreshing the challenge.

OK.

> maybe we ought engineer one:-).

The fact that there's a plethora of examples really speaks to not
calling out one company on this, as well as that it's not necessary to
do so.  We could just say "the many password exposures that have been
well documented in the media," for example.

(On the DISCUSS criteria, "This cannot be an exhaustive list, but this
set should be taken as exemplary of the common causes for DISCUSSes
seen by the IESG in the past."  This is a rare situation, so, of
course, it's not explicitly listed.  I can only say again that I think
it's a bad idea to call out specific companies unless there's a strong
need to.)

>    mislead by the zero length encoding required."

Actually, that helps; now I understand what you were trying to say
(and, now that I've seen that text, I understand the original... but I
honestly couldn't make sense of the original before).  So:

NEW
Both sides know when this needs to be there, without needing to rely
on the zero-length encoding.
END

I think what I mostly tripped over was the missing comma after "needs
to be there", which confused me about the role of "ïndependent" in the
sentence.  So if you like the current wording, maybe just add the
comma.

> Yes, your ask is small. But is it a real improvement?

I think it is, because it tells the reader where the issue is discussed.

But it's non-blocking, so if you really object to that, I've had
enough of my say there.

> a different attitude than I towards 2119

He-he.  Yeh, ack.

> But the honest answer again is: I don't recall and don't think it

Yeh, I don't either; it was just a question.  Done here.

>>>> I suggest switching sections 6.2.2 and 6.2.3.
...
> other things being equal we order the sections alphanumerically

C'mon, hardly a reasonable comparison.  We don't usually mix "good
ideas" and "bad ideas" rather arbitrarily: usualy organization puts
the good ideas together, and the bad ones together.  Anyway, again:
done here; do as you think best.

> will ever understand this sentence.

I really didn't want to talk about this further, but I have to respond
to this: you're recommending that implementors give users an option
that will be useless to almost all users.  That's what I'm (minorly)
carping on, and (mostly) I'm asking if there's something you can say
to implementors that will help them do something that's actually
useful to users.  That's all.

> of course. And I don't think we need this (again experimental!)

Yeh, probably right.  I was asking if there was something useful you
could say.  "Nothing that comes to mind," is a fair answer to that.

> Why? Where's it say that?

In 2119.

> I think a DE is quite capable of getting the ask here.

Yes, true.

> Sure. As long as its small:-)

No, I mean is there any advice to DEs about what to review in regard
to these registries (forget about the number of entries).  In 9.3 you
said that the DE should consider the use of the algorithms in IETF
protocols.  Great.  Any advice of that nature here?  Or do we want to
DE to wing it?

Barry

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Jan 2015 07:29:11 +0100

> kind of regurgitation. It's just a bad idea.)

As I'm mentioned...

FWIW I found the document really confusing as well; a complete example 
exchange of the bits on the wire would be extremely helpful.

Best regards, Julian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 08:10:24 +0000

Thanks for updating the ballot. I'll process your comments separately
so this is just on the remaining DISCUSS point.

>>> >> important to leave it there), then the discussion will have happened,

Yet here we still are? :-)

> calling out one company on this, 

I re-iterate: At the time of writing this was the poster-child
example. It still remains one, and a good one for RFC readers.

> as well as that it's not necessary to

That may be a reasonable comment, but I continue to maintain that
it is not DISCUSS-worthy. And I think being so shy about this is
a bad plan actually and we ought if anything be more direct about
it.

> it's a bad idea to call out specific companies unless there's a strong

"bad idea" does not mean DISCUSS-worthy, and extending the DISCUSS
criteria in that way seems very wrong to me.

The DISCUSS non-criteria also exists though, quoting, I think this falls
squarely under two of those:

"
- Pedantic corrections to non-normative text. Oftentimes, poor phrasing
or misunderstandings in descriptive text are corrected during IESG
review. However, if these corrections are not essential to the
implementation of the specification, these should not be blocking
comments.

- Stylistic issues of any kind. The IESG are welcome to copy-edit as a
non-blocking comment, but this should not obstruct document processing.
"

I think in a case like this it is entirely correct to reference well
publicised security incidents in the most natural fashion via the name
of the organisation that experienced the incident. In this case, I
re-iterate that that incident was I think the most commonly cited one
at the time of writing. (I can buy that adding a citation for more
detail would be a good addition though.)

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 08:12:29 +0000

On 06/01/15 06:29, Julian Reschke wrote:
> FWIW I found the document really confusing as well; 

Hmm. I didn't get that from your earlier reviews. Did I miss
something? If there are specific things are confusing that would
get in the way for an implementer then I'd be glad to know about
those but I thought all the points you raised in your reviews of
this had been addressed.

> a complete example

Noted.

S.

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jan 2015 16:20:39 +0800

...
...
> Yet here we still are? :-)

Because I think the discussion needs to continue.  I still don't
understand why you think it's so important to single out LinkedIn,
such that it's worth the damage that having that in an RFC represents.

> example. It still remains one, and a good one for RFC readers.

It was not "the poster child": there have been so many of these
breaches, both before and since, that I see no reason at all to call
out any one instance.

> a bad plan actually and we ought if anything be more direct about

I don't think text such as what I suggest -- text that does not name
specific companies that got hacked -- is being shy.  Actually, I think
it makes a *stronger* statement to say that there have been many, and
that they have made big news worldwide.

> criteria in that way seems very wrong to me.

"Bad idea" in this case means, to me, bad for the IETF.  I think it's
just wrong.

This is not a "pedantic correction" nor a "stylistic issue" -- it is,
to me, an important point.  You and I clearly don't agree on this, so
let's see what other ADs think as they fill out their ballots.

> detail would be a good addition though.)

I understand that's what you think.  As I say, we disagree, apparently strongly.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 08:39:10 +0000

> such that it's worth the damage that having that in an RFC represents.

There is no additional damage to them (unless via this discussion
ala Streisand;-) and I don't see any damage to the IETF from a
mention of that being in an RFC - it was a real and really well
publicised incident, us mentioning it in an RFC will not put it
back on the front pages as it was at the time.

> breaches, both before 

We disagree there as to the facts. My recollection is that it very
much was the poster child at the time of writing. But we might of
course both be recalling imperfectly.

> and since, that I see no reason at all to call
> out any one instance.
> 
> to me, an important point. 

Sure I accept that you think this important.

> You and I clearly don't agree on this, 

Very much so.

> so

Yep.

> I understand that's what you think.  As I say, we disagree, apparently strongly.

I strongly disagree with this comment being a DISCUSS point.
Were there a blatant error in the text that might be defensible
but there is not, that incident did happen and was very widely
publicised. [1]

   [1] https://en.wikipedia.org/wiki/2012_LinkedIn_hack

I far less strongly disagree about the text that ought be in
the RFC - that is, my main problem with your comment is that it
is a blocking DISCUSS point.

Cheers,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 09:47:28 +0000

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

> 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

Fixed.

> Does that mean that "challenge" and max-age can appear more than

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.

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

Fixed.

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

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

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

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jan 2015 17:54:38 +0800

> A proto -10 version with changes indicated below is at [1] the

Will try to look at that later (Tues evening, China time).

> And I'll happily look at that when it's available. (And hope to

That's also on the schedule for after dinner.

> TBH, I prefer the current text a lot.

OK; thanks for having a look (and also for some of the other items).

> local only and will re-use the same password in more than one place).

A good point, which I hadn't considered; thanks.

> but I think it fits better now.

Will look tonight, but I bet you're right.

> added that specific point and did tweak a bit though.

T'anks.

OK.

b

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jan 2015 17:59:53 +0800

> Will try to look at that later (Tues evening, China time).

Got a chance to look at the diffs now; yes, it looks good, and thanks again.

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 6 Jan 2015 08:47:14 -0500

Stephen & Barry,

Thank you both for working through this.  I'm caught up now as I was
asleep during the exchange.  I want to make sure I understand where we
are at now.

Barry will propose text that lists out the steps requested in his
original discuss.  I think this could be a helpful addition.  I was
fine with the text of the draft as-is, but see that different people
think differently and this addition could be helpful.  I had to add in
something similar in one of my drafts even though I and a few others
thought the steps were clear, in the end it was helpful to some.

The other item was on LinkedIn and I think we are ok now on the text
change, is that right?  To see if I can help, I do agree with Stephen
here and hope the updated text is enough to move forward on this one
(it seems to be the case).  If the LinkedIn attack is mentioned, most
know that it was a large scale attack against the passwords stored on
the server side.  For what it's worth, just the mention of an attack
is not necessarily bad press.  Most look at how a company handled an
attack and the aftermath now rather than the fact that one happened.
Sometimes it is positive and most of the time it turns out to positive
for companies (even TJ Max had an increase in sales after their breach
that involved compromised Point of Sale systems).

Barry, as an FYI, the focus on passwords is partly due to my review as
that is what this draft is helping to solve.  I wanted text removed
that talked about phishing attacks because they are far more
complicated than just passwords and can involve lots of different
types of credentials.  I do think the focus on passwords is more
appropriate.

Thank you,
Kathleen

On Tue, Jan 6, 2015 at 4:59 AM, Barry Leiba <[email-masked]> wrote:
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Tue, 6 Jan 2015 14:05:29 +0000

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

And here we go; not a lot, but I think it really helps.  Of course, adjust it if I got anything wrong or worded inaccurately.  Note how the section references jump around -- that's why I found it hard to follow, and why I think this is a big help.  I'm suggesting making this Section 1.3 because I think having it up front makes it the most useful.

-------------------------------------
1.3 An Overview of HOBA-http Authentication

HOBA authentication uses the HTTP authentication framework defined in 
[RFC7235], using a number of HOBA-specific elements.  This is a high-level 
overview of HOBA-http authentication:

1. If the user is not already registered with the web-origin and realm it is 
trying to access, the "joining" process is invoked (see Section 6.1).  This 
creates a key pair and makes the CPK known to the server.

2. The client connects to the server and makes a request, and the server's 
response includes a WWW-Authenticate header field that contains the "HOBA" 
auth-scheme, along with associated parameters (see Section 3).

3. The client uses the challenge from the HOBA auth-scheme parameters, along 
with other information it knows about the web-origin and realm, to create 
and sign a HOBA-TBS string (see Section 2).

4. The client creates a HOBA client-result (HOBA-RES), using the signed 
HOBA-TBS for the "sig" value (see Section 2).

5. The client includes the Authorization header field in its next request, 
using the "HOBA" auth-scheme and putting the HOBA client-result in an 
auth-param named "result" (see Section 3).

6. The server authenticates the HOBA client-result (see Section 5.3).

7. Typically, the server's response includes a session cookie that allows 
the client to indicate its authentication state in future requests (see 
Section 1.1).

[You might include an example here, as Julian suggests.  Or perhaps you might put an example in an appendix, and just cite it here.]

-------------------------------------

Please let me know what you think.

Barry

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 06 Jan 2015 14:48:09 +0000

Hiya,

On 06/01/15 14:05, Barry Leiba wrote:
>> And I'll happily look at that when it's available. (And hope to not
>> have to wait much:-)
> 
> And here we go; 

Thanks for being timely.

> not a lot, but I think it really helps.  Of course,
> adjust it if I got anything wrong or worded inaccurately.  Note how
> the section references jump around -- that's why I found it hard to
> follow, and why I think this is a big help.  I'm suggesting making
> this Section 1.3 because I think having it up front makes it the most
> useful.

Yeah, TBH I think that's superflous but harmless and doesn't
replicate text already elsewhere so I've put it in (same [1,2]
as before work) almost as-is.

Cheers,
S.

> 
> ------------------------------------- 1.3 An Overview of HOBA-http
> Authentication
> 
>  [RFC7235], using a number of HOBA-specific elements.  This is a
> high-level overview of HOBA-http authentication:
> 
> 1. If the user is not already registered with the web-origin and
> realm it is trying to access, the "joining" process is invoked (see
> Section 6.1).  This creates a key pair and makes the CPK known to the
> server.
> 
> 2. The client connects to the server and makes a request, and the
> server's response includes a WWW-Authenticate header field that
> contains the "HOBA" auth-scheme, along with associated parameters
> (see Section 3).
> 
> 3. The client uses the challenge from the HOBA auth-scheme
> parameters, along with other information it knows about the
> web-origin and realm, to create and sign a HOBA-TBS string (see
> Section 2).
> 
> 4. The client creates a HOBA client-result (HOBA-RES), using the
> signed HOBA-TBS for the "sig" value (see Section 2).
> 
> 5. The client includes the Authorization header field in its next
> request, using the "HOBA" auth-scheme and putting the HOBA
> client-result in an auth-param named "result" (see Section 3).
> 
> 7. Typically, the server's response includes a session cookie that
> allows the client to indicate its authentication state in future
> requests (see Section 1.1).
> 
> [You might include an example here, as Julian suggests.  Or perhaps
> you might put an example in an appendix, and just cite it here.]
>

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Jan 2015 08:02:09 -0800

Thanks, Barry. The programmer in me thinks these are very useful too.

Mike

On 01/06/2015 06:05 AM, Barry Leiba wrote:
> 1.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 06 Jan 2015 08:24:43 -0800

> breaches, both before and since, that I see no reason at all to call

I'm pretty sure that I'm responsible for the offending text and it was 
enough of a a poster child
in my mind because my JS implementation was a direct response in an 
"enough is enough" way. Yes,
there have been lots of these but if a large, well known, well funded 
company is vulnerable, how
can we expect everybody else to not fall prey? The problem isn't with 
LinkedIn per se -- and it makes
me extremely angry when the finger waggers inevitably blame end users -- 
it's with password schemes
in general, which is a failure of engineering.

FWIW, I don't see LinkedIn in this case as "name and shame" but more of 
"this too can be YOU"
example. For that reason, I think it's better to leave it in as a 
cautionary tale instead of diluting it
down to non-specific "others".

Mike

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 08 Jan 2015 11:52:56 +0900

> that involved compromised Point of Sale systems).

This almost sounds as if making sure you get hit once in a while and 
your user's data gets stolen is a good thing :-(.

I seriously hope that's not the case.

Regards,   Martin.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Jan 2015 22:00:53 -0500

Sent from my iPhone

> On Jan 7, 2015, at 9:52 PM, "Martin J. Dürst" <[email-masked]> wrote:
> 
> This almost sounds as if making sure you get hit once in a while and your user's data gets stolen is a good thing :-(.

Martin,

What I typed was to help with an explanation, not actual text to be used in a draft.  It was an example (that can be backed up with data) to say it's not uncommon or looked at poorly to name companies when referring to specific attack types.  How they respond is important and I did not say anything about repeated attacks, that or severity can have an effect on a business, but really would have been getting too far off the point of whether or not it's okay to name LinkedIn.

Best regards,
Kathleen