Subject: Re: New Non-WG Mailing List: unbearable

From: John C Klensin <[email-masked]>
Date: Fri, 05 Dec 2014 14:49:41 -0500

As a member of or sympathizer with various societies for bear
encouragement and preservation (black, brown, polar, Cub Scouts,
Teddy, Pooh, ... in no particular order), I find this name
really objectionable.  From the description, "unbearerable"
might have been better, "betterbearer" certainly would have been.

"unbearable" should be reserved for April 1 RFCs and similar
work efforts :-)

I wonder if anyone has ever appealed a mailing list name.

unbearably yours,
    john

--On Friday, December 05, 2014 11:18 -0800 IETF Secretariat
<[email-masked]> wrote:

> A new IETF non-working group email list has been created.
> 
> List address: [email-masked]
> Archive: http://www.ietf.org/mail-archive/web/unbearable/
> To subscribe: https://www.ietf.org/mailman/listinfo/unbearable
> 
> Purpose:
> 
> This list is for discussion of proposals for doing better than
> bearer tokens (e.g. HTTP cookies, OAuth tokens etc.) for web
> applications. The specific goal is chartering a WG focused on
> preventing security token export and replay attacks.

---

From: Derek Atkins <[email-masked]>
Date: Sat, 06 Dec 2014 14:19:34 -0500

Hi,

IETF Secretariat <[email-masked]> writes:

> This list is for discussion of proposals for doing better than bearer
> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web

The OAUTH Working Group is already (and has been for a while!) looking
into "holder of key" protocols to improve upon Bearer Tokens.

I would suggest that this work happen there instead of creating a whole
new group for it.

-derek

> For additional information, please contact the list administrators.

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Mike Jones <[email-masked]>
Date: Mon, 8 Dec 2014 21:58:58 +0000

It's my understanding that "Unbearable" is part of an effort to create a new working group scoped to work on deliverables based upon these input documents:

http://tools.ietf.org/html/draft-balfanz-https-token-binding
http://tools.ietf.org/html/draft-popov-token-binding

I don't think that it was ever intended to cover every aspect of proof-of-possession and so there's not actually any conflict with the work we're already doing in OAuth.  (Nor does it seem to me to be productive to add even more documents-in-flight to the OAuth working group at present.)

				Cheers,
				-- Mike

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Derek Atkins
Sent: Saturday, December 06, 2014 11:20 AM
To: [email-masked]
Cc: Andrei Popov; [email-masked]; Stephen Farrell
Subject: Re: [Unbearable] New Non-WG Mailing List: unbearable

Hi,

IETF Secretariat <[email-masked]> writes:

> tokens (e.g. HTTP cookies, OAuth tokens etc.) for web applications. 
> The specific goal is chartering a WG focused on preventing security 
> token export and replay attacks.

The OAUTH Working Group is already (and has been for a while!) looking into "holder of key" protocols to improve upon Bearer Tokens.

I would suggest that this work happen there instead of creating a whole new group for it.

-derek

_______________________________________________
Unbearable mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/unbearable

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 08 Dec 2014 23:23:09 +0000

Hiya,

As the sponsoring AD (or whatever term's correct) I've kicked
off the discussion on the new list. [1] If you're interested then
please subscribe there and discuss away. I really don't think
we need to bother [email-masked] with all the details.

Thanks,
Stephen.

[1] https://www.ietf.org/mail-archive/web/unbearable/current/msg00008.html

---

From: Phil Hunt <[email-masked]>
Date: Mon, 8 Dec 2014 15:17:30 -0800

Maybe all token work should be together in its own WG?

Phil

> On Dec 8, 2014, at 14:54, John Bradley <[email-masked]> wrote:
> 
> We did discuss this at the last IETF meeting.
> 
> While the work is closely related to the PoP work in OAuth it is not the same.  It will allow us to do PoP tokens for the implicit flow, something that we haven't touched yet in OAuth because we don't have a workable way to manage keys in the browser.   This work should allow us to do that.
> 
> I think the slide deck examples showing JWT using different mechanisms to express keys from the work done in the OAuth WG may be part of what has some people concerned.
> 
> I don't think these specs overlap with OAuth, but we do need to be mindful of scope creep.   As I stated at the F2F we need to have the two groups work together, so that we can have PoP tokens via the browser.  
> 
> John B.
> 
> 
>> On Dec 8, 2014, at 6:58 PM, Mike Jones <[email-masked]> wrote:
>>

---

From: John Bradley <[email-masked]>
Date: Mon, 8 Dec 2014 19:54:18 -0300

John B.

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Dec 2014 11:29:25 -0600

> I would suggest that this work happen there instead of creating a whole

That's very interesting.

Key confirmation protocols will tend to all look... roughly similar: a
synchronous exchange of "messages" (with cryptographic elements, of
course) between a "client" and a "server" (with perhaps infrastructure
message in the background) until one, the other, or both peers are
authenticated to the other, or the authentication fails.

If you can have keys at all, you can also have session keys, though for
HTTP.. until we get something better than web cookies for session
continuation, having session keys is hardly critical.

Anyways, there's a reason I mention this: we already have several
protocols that look like this, so new not-just-bearer-anymore bearer
token extensions have literature to look at.

A brief list of such protocols that might be useful for lessons to
good, bad, and ugly: TLS, SASL (and various mechanisms), GSS-API (and
various mechanisms), Kerberos V5, IKEv1 and IKEv2, ...

Of those, these tend to have actual APIs in the wild that might be
useful too: TLS (ad-hoc APIs), SASL (ad-hoc APIs), GSS (standard APIs),
Kerberos (ad-hoc APIs), IKEv* (PF_KEY -- a standardish socket API).

I'm not sure which lessons OAuth and others going down this path should
take.  I'll try to think of some so as to save the authors the time of
having to digest all this material.  I suggest others also do this.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Tue, 9 Dec 2014 11:36:42 -0600

> might have been better, "betterbearer" certainly would have been.

If the outcome is intended to be proof-of-possession extensions that
render bearer token schemes no-longer-bearer... then "unbearable" seems
better than "betterbearer", though I agree with you that "unbearable"
comes across as potentially insulting.  Maybe we should all be thick-

> I wonder if anyone has ever appealed a mailing list name.

The risk here is that key participants might simply... ignore it until
it's too late.  I think the AD can probably do some promotion to try to
avoid such an outcome.

Nico

[*] If there is such a medical problem as having thin skin, note that
    this is just a manner of speaking; no offense meant.

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Dec 2014 14:30:16 -0500

--On Tuesday, December 09, 2014 11:36 -0600 Nico Williams
<[email-masked]> wrote:

>> encouragement and preservation (black, brown, polar, Cub
>> Scouts, Teddy, Pooh, ... in no particular order), I find this
>> name really objectionable.  From the description,
>> "unbearerable" might have been better, "betterbearer"
>> certainly would have been.
> 
> If the outcome is intended to be proof-of-possession
> extensions that render bearer token schemes
> no-longer-bearer... then "unbearable" seems better than
> "betterbearer", though I agree with you that "unbearable"
> comes across as potentially insulting.  Maybe we should all be
> thick- skinned[*] enough to get the joke and move on, but:
> 
> The risk here is that key participants might simply... ignore
> it until it's too late.  I think the AD can probably do some
> promotion to try to avoid such an outcome.

Nico,

I was trying to keep the complaint light and at least slightly
humorous, but I am concerned that we seem to often choose names
for passing amusement value that later turn out to cause
confusion, bad attitudes or worse.  Those reactions sometimes
occur in communities who are not normally visible in the IETF.
It may also be that my periodic involvement with the collection
of policy, strategy, organizational, administrative, and
regulatory issues that are mischaracterized as "Internet
governance" (more outside the IETF than inside) has left me
oversensitive, but I've had to listen to discussions --in
obvious and not-so-obvious places-- in which the IETF is
dismissed as a bunch of small children who are too impressed by
their own cleverness and busy and  with activities like
self-congratulatory giggling about their latest in-joke or
esoteric debate about things that make no difference to be taken
seriously.  

Independent of how important those reactions actually are, with
the sorts of discussions going on that have been represented
here by the Internetgovtech and IANAPlan efforts, various
clusters of countries trying to impose their own views about how
the Internet should be structured and where those topics should
be discussed, reviews of IGF and other discussion arrangements
in progress, etc., it is probably not the best time to exhibit
how clever we can be about silly names for Working Groups,
Mailing Lists, or other activities.

In that context, the risk of an appeal is that it would call
even more unwanted attention to the topic.

Just my opinion, of course.
   john

---

From: Douglas Otis <[email-masked]>
Date: Tue, 9 Dec 2014 12:03:57 -0800

> even more unwanted attention to the topic.

Dear John,

Agreed.  Those within the IETF might be concerned even a simple concept is too politically charged.  Perhaps a mailing-lists "soap-box" might divert distractions without curtailing individual expression.

Regards,
Douglas Otis