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

[Kathleen Moriarty <[e-mail]>]

Sent from my iPhone

> On Jan 7, 2015, at 6:12 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 
> 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;-)
> 
Good catch, thanks Alissa.
>> 
>> 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.
I think it's better to replace this text, I agree with Alissa that other cultures may have problems with it.

Thanks,
Kathleen 
> 
>> 
>> = 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.
> 
> 
>> 
>>