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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 07 Jan 2015 14:20:27 -0800

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?

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

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.

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

= Section 8.2 =

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Jan 2015 23:12:57 +0000

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

> http://datatracker.ietf.org/doc/draft-ietf-httpauth-hoba/

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

> IMEI-ilk are envisioned, and if so what the purpose of them is expected

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

> absent then the "string" form of device identifier defined in Section 9.5

Sure

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

> If you want to leave in the LinkedIn reference, or any specific example,

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Jan 2015 19:39:09 -0500

Sent from my iPhone

> On Jan 7, 2015, at 6:12 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 
> Hiya,
> 
Good catch, thanks Alissa.
> surely the threat is so obvious that the "fun and profit" colloquialism
I think it's better to replace this text, I agree with Alissa that other cultures may have problems with it.

Thanks,
Kathleen

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Jan 2015 18:39:17 -0600

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

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 7 Jan 2015 19:58:53 -0500

Sent from my iPhone

> On Jan 7, 2015, at 7:39 PM, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 
> 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.
> 

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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jan 2015 01:10:08 +0000

On 08/01/15 00:39, Kathleen Moriarty wrote:>>> >> = Section 8 =

> cultures may have problems with it.

Alissa didn't mention other cultures but a form of speech, at least
as I read her comment, and a form of speech that wasn't intended
as it happened;-)

In this case the colloquialism is colloquial to security nerds and
not people from a particular lat/long. So yes, we could replace this
but IMO that'd be us being silly, as it's a quite well known
phrase for security researchers [1] and, turns out, (and I
didn't know) is actually not very modern. [2]

S.

[1]
http://scholar.google.com/scholar?hl=en&q=%22fun+and+profit%22&btnG=&as_sdt=1%2C5&as_sdtp=
[2]
https://english.stackexchange.com/questions/25205/what-is-the-origin-of-phrase-for-fun-and-profit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 7 Jan 2015 19:13:22 -0600

>> > > Please refer to
http://www.ietf.org/iesg/statement/discuss-criteria.html
>> 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.
> 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.

This all makes sense to me.

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

I think the question is whether we think the readers of this RFC (to be)
will have the security community mindset, or whether there will be a
broader audience.

I have no idea which of those is the case, of course.

Spencer

---

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 08 Jan 2015 11:48:17 +0900

> I have no idea which of those is the case, of course.

What about *both*?   Regards,   Martin.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 8 Jan 2015 12:01:36 -0800

> didn't know) is actually not very modern. [2]

Re sarcasm: I assumed it was sarcastic because if you read the sentence literally, it doesn’t make sense. Why would you normatively recommend against something that is fun and profitable? Of course I know what the colloquialism implies, but anyone who is not familiar with the colloquialism — whether because they are non-native English speakers or come from a “culture” that is not the security-clueful culture — may not. Furthermore, given that the way the phrase is used is a variation on the original, a Google search doesn’t actually produce helpful results in the first couple of pages (whereas searching on “for fun and profit” yields the most salient result in the top spot).

I hate to lose our colloquialisms and inside jokes as much as the next person, but for RFCs I disagree that it’s us being silly. It’s us lowering barriers for those unfamiliar with the phrases and jokes to understanding and using the output of the IETF. There are plenty of other places where we can still be colloquial.

Alissa