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

[Spencer Dawkins at IETF <[e-mail]>]

On Jan 8, 2015 7:13 AM, "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;-)
>
> >
> > 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:-)

For what it's worth, I like using a reference for this. Thank you, Alissa,
for making the suggestion, and thank you, Stephen, for making the change.

I understand the point about the LinkedIn example being a Big Hairy Deal,
so pointing to it sounds like a plan.

I wonder if it's more effective to say "this happens all the time" in the
text, which I understand to be the case, with the reference being to
LinkedIn.

I'm no security maven, but when I was reading recently about Sony's wizard
security practices, I thought to myself, "I'd never do anything that dumb",
and kind of stopped there. I wonder if that's more likely if the text calls
out any single company.

Spencer, who may still be too nice to be an AD ...

> Cheers,
> S.
>
>
> >
> >
>