Re: [http-auth] Alissa Cooper's No Objection on draft-ietf-httpauth-hoba-09: (with COMMENT)

[Stephen Farrell <[e-mail]>]

Hiya,

Two non-trivial changes here, see below, but also please check that
though, working copy is at [1], diff vs. -09 at [2] as usual.

   [1] https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt
   [2]
https://tools.ietf.org/rfcdiff?url1=draft-ietf-httpauth-hoba-09.txt&url2=https://down.dsg.cs.tcd.ie/misc/draft-ietf-httpauth-hoba-10.txt

On 07/01/15 22:20, Alissa Cooper wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-httpauth-hoba-09: No Objection
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Good stuff! Couple of comments.
> 
> = Logging out =
> 
> The intro says
> 
> "Logout features can be useful for UAs, so HOBA defines a way to
>       close a current HTTP "session", and also a way to close all
>       current sessions, even if more than one session is currently
>       active from different UAs for the same account."
>     
> But the method specified in 6.3 seems to only accomplish the first of
> these (assuming the recommendation about server deletion of cookies
> related to "the session" is meant to be specific to one session). What is
> the method for logging out of all sessions associated with different UAs
> for the same account?

Oops that's a relic, good catch. Deleted from "...and also a way" to
the end. My code doesn't have that anymore, I didn't check other
folks. We could always add it back later if needed, it'd just be one
more .well-knonw/hoba thing. (And in case you ask, sorry but I forget
when/why we dropped that or if it was because it didn't work or out
of laziness or someone's objection:-)

> 
> = Section 6.1 =
> 
> Either the device identifier/device identifier type bits are
> underspecified, or it's not clear to me how they are meant to be used.
> What other device identifier types are expected to be used in the future,
> such that a registry of them is necessary? To me it seems like you would
> want UAs/users to take some care with the precision of the device
> identifiers shared with servers -- e.g., "Alissa's laptop" seems like it
> could be useful and fairly safe, whereas "IMEI 013584009812219" seems
> like total overkill and a bad idea. (As an aside, it might be good to
> provide some guidance about this in the document.) The creation of the
> registry makes me wonder if more structured device identifiers of the
> IMEI-ilk are envisioned, and if so what the purpose of them is expected
> to be?

Nobody had mentioned IMEIs but that's a very good point since most
devices have something like that it'd be bad to use. The idea of the
registry for dids was that they might be part of the registration
flow that a site used (hence not specified here), so e.g. account
creation for phones might differ from that for tablets or laptops.
(And no, I don't think we yet know enough to do a good job on defining
those right now, so how to use this well would be a part of the
experiment I figure. And now I'm hoping we don't get asked to say
all that in the draft;-)

I added text about possible privacy issue in both 8.1 and 9.5.

8.1, NEW:

   Device identifiers are intended to specify classes of device in a way
   that can assist with registration and with presentation to the user
   of information about previous sessions, e.g.  last login time.

   Device identifier types MUST NOT be privacy sensitive, with values
   that would allow tracking a user in unexpected ways.  In particular,
   using an device identifier type that is analogous to the
   International Mobile Equipment Identifier (IMEI) would be a really
   bad idea and is the reason for the MUST NOT above.  In that case
   "mobile phone" could be an acceptable choice.

   If possible, implementations ought encourage use of device identifier
   values that are not personally identifying except for the user
   concerned, for example "Alice's mobile" is likely to be chosen and is
   somewhat identifying but "Alice's phone: UUID 1234-5567-89abc-def0"
   would be a very bad choice.

9.5, NEW:

   The designated expert for this registry is to carefully pay attention
   to the notes on this field in Section 8.1, in particular the "MUST
   NOT" stated therein.

Happy to wordsmith that some more and we probably will want to.

(Isn't it interesting how even those of us who care about this kind of
thing can miss it entirely;-)

> 
> Also, I would suggest
> 
> s/if absent then the "string" form of device identifier MUST be used./if
> absent then the "string" form of device identifier defined in Section 9.5
> MUST be used.

Sure

> 
> = Section 8 =
> 
> "Binding my CPK with someone else's account would be fun and
>    profitable so SHOULD be appropriately hard."
> 
> Sarcasm translates pretty poorly across cultures. I would suggest saying
> what you actually mean here.

Wasn't meant to be sarcastic at all. I guess it is a little opaque but
surely the threat is so obvious that the "fun and profit" colloquialism
is ok.

> 
> = Section 8.2 =
> 
> If you want to leave in the LinkedIn reference, or any specific example,
> it needs a citation.

Yep, I added one to the working copy. It's wikipedia but I've wrangled
that with the RFC editor before via the wiki permanent URL feature:-)

Cheers,
S.


> 
>