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

[Barry Leiba <[e-mail]>]

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

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

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.

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

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

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

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.

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

OK; removing that item as well now; thanks.

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

OK.

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

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

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

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.

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

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

He-he.  Yeh, ack.

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

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

>>>> It seems odd to put the NOT RECOMMENDED mechanism in the middle;
>>>> I suggest switching sections 6.2.2 and 6.2.3.
...
> 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.

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.

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

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.

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

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.

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

In 2119.

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

Yes, true.

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

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