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

[Stephen Farrell <[e-mail]>]

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

> 
>> 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.
> 
> 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?
>> 
>> The previous len field tells you.
> 
> 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?
>> 
>> 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.
> 
> 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 think it's clear to be honest.
> 
> 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 think it's clearer as-is to be honest.
> 
> 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?
>> 
>> Sorry I don't see a problem.
> 
> 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.
>> 
>> I'm fine with it as-is to be honest.
> 
> 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.
>>> 
>>> 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.)
> 
> 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?
>> 
>> 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.
> 
> 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
>