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 7:39 PM, Spencer Dawkins at IETF <[e-mail]> wrote:
> 
> 
> 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 ...
> 

For big attacks, the security folks tend to name the first or a big recent example of a specific attack.  When you say the LinkedIn attack, I remember that there was some crazy large (I think a million+) number of passwords stolen from at he server side.  This caused a lot of questions from friends and lots of password changes (well publicized).  In response to Barry's question on this that led to Stephen's update, I mentioned that most look at how a company responds in terms of reputation as opposed to the fact that an event occurs.  Business usually goes up as crazy as that sounds.  RSA gets mentioned when the discussion is about APTs or the trend in supply chain attacks. I hope this was helpful.

Does the new language help enough?  I think it does, but  another security person.

Thanks,
Kathleen
> > Cheers,
> > S.
> >
> >
> > >
> > >
> >