Subject: Submitter authorization by ID submission tool

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Nov 2007 20:21:25 +0000

Hi,
I recently noticed that the web submission tool allows a third party to 
submit updates to drafts edited by other people. While this is very 
handy if somebody starts co-editing a document or takes over editing of 
a document, the tool doesn't seem to require any authorization from 
original authors (or from WG chairs) that the new [co-]editor is 
actually allowed to take over. This seems like a bug to me.

I hope nobody would dare to use the feature for stealing somebody elses 
draft.

Regards,
Alexey

P.S. Disclaimer - I think that the web draft submission tool is great, I 
just think that the feature described above was not intended.

---

From: "Eric Rescorla" <[email-masked]>
Date: Wed, 28 Nov 2007 12:39:32 -0800

It seems to me that this has always been a feature of the email
system, forgery being as easy as it is.

-Ekr

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Nov 2007 20:46:36 +0000

>system, forgery being as easy as it is.
Maybe true, but when I took over editing, I was asked several times to 
get authorization from the original author or WG chair.

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 28 Nov 2007 14:46:33 -0600

The same situation applies to manual submission - no?

And I'm not saying that's a BAD thing. We mostly handle submarine patents by 
flailing people on IETF lists, and I'd be a lot more concerned about someone 
with a submarine patent than someone who submitted 
draft-dawkins-whatever-03.

I'd also be concerned if people could tell the difference (in my case), and 
whether they preferred the fake version of the draft...

:-)

Spencer

> submit updates to drafts edited by other people. While this is very handy 
> if somebody starts co-editing a document or takes over editing of a 
> document, the tool doesn't seem to require any authorization from original 
> authors (or from WG chairs) that the new [co-]editor is actually allowed 
> to take over. This seems like a bug to me.
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 28 Nov 2007 12:59:35 -0800

Security analysis by analogy is not very convincing.
 
We live in a different world as far as patents are concerned. I think it would be a good thing if we adopted a federated authentication protocol that would allow us to meet this particular set of requirements - i.e. a strong binding to the domain of the submitter.
 
Seems to me that the email callback scheme we have is almost good enough.

________________________________

From: Eric Rescorla [mailto:[email-masked]]
Sent: Wed 28/11/2007 3:39 PM
To: Alexey Melnikov
Cc: Working Group Chairs
Subject: Re: Submitter authorization by ID submission tool

-Ekr

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 28 Nov 2007 22:37:34 +0100

Hi Alexey,

> actually allowed to take over. This seems like a bug to me.

Hmm.  If the implementation permits this, it's both a bug and a failure
to follow the specification (RFC 4228).

Have you observed this succeed, or have you only inferred that it could
succeed from the web pages / documentation?

> I hope nobody would dare to use the feature for stealing somebody elses 

Agreed, and I'd say we need to plug the hole if it does exist.

	Henrik

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Nov 2007 12:23:21 +0000

Henrik Levkowetz wrote:

>Have you observed this succeed,
>
Yes, I started co-editing two drafts recently (one individual and one WG 
document). Nobody asked me if I was authorized to take over.

Also my co-worker submitted a replacement for an expired draft. He 
removed name of the original author (because the original author asked 
him to). No checks were done either.

>or have you only inferred that it could

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Nov 2007 13:44:51 -0600

This feels like an opportunity to make trouble for ourselves.

I spent a few minutes thinking about what we would _do_ to get that  
chair or original author approval in some built-in-the-tool way and  
most of what I've thought of has failure and exception conditions  
that would be almost impossible to code around (These look like "a  
human has to fix it when a valid submission was made, but the tool  
can't figure out that it was valid" and "a human has to fix it when a  
valid submission was made, but the tools ways to approve things  
hasn't anticipated someone moving, a chair changing, etc). Sure, lots  
of effort can go into making the number of exception conditions as  
small as possible, but I'm not sure the effort isn't better spent  
somewhere else.

If somebody _did_ do an improper thing and attempt to hijack a draft,  
somebody (usually a lot of angry somebodies) is going to notice and  
complain and a human's going to fix it.
How often has this happened with the email submission process we've  
used to date? Has it been often enough to warrant investing in a tool  
solution
rather than a human-fixes-it solution? At the moment, I don't think  
it is.

RjS

On Nov 29, 2007, at 6:23 AM, Alexey Melnikov wrote:

>>> I recently noticed that the web submission tool allows a third  
>>> party to submit updates to drafts edited by other people. While  
>>> this is very handy if somebody starts co-editing a document or  
>>> takes over editing of a document, the tool doesn't seem to  
>>> require any authorization from original authors (or from WG  
>>> chairs) that the new [co-]editor is actually allowed to take  
>>> over. This seems like a bug to me.
>>>
> Yes, I started co-editing two drafts recently (one individual and  
> one WG document). Nobody asked me if I was authorized to take over.
>
> removed name of the original author (because the original author  
> asked him to). No checks were done either.
>
>>> I hope nobody would dare to use the feature for stealing somebody  
>>> elses draft.
>>>

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 29 Nov 2007 14:21:09 -0600

I agree - especially given what the tools team could be working on, if they 
didn't have to protect us from ourselves on this particular threat...

Spencer

> I spent a few minutes thinking about what we would _do_ to get that  chair 
> or original author approval in some built-in-the-tool way and  most of 
> what I've thought of has failure and exception conditions  that would be 
> almost impossible to code around (These look like "a  human has to fix it 
> when a valid submission was made, but the tool  can't figure out that it 
> was valid" and "a human has to fix it when a  valid submission was made, 
> but the tools ways to approve things  hasn't anticipated someone moving, a 
> chair changing, etc). Sure, lots  of effort can go into making the number 
> of exception conditions as  small as possible, but I'm not sure the effort 
> isn't better spent  somewhere else.
>
> How often has this happened with the email submission process we've  used 
> to date? Has it been often enough to warrant investing in a tool  solution
> rather than a human-fixes-it solution? At the moment, I don't think  it 
> is.
>
> RjS

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 29 Nov 2007 19:46:40 -0500

+1

As far as I know there has never been a problem with this. And the IETF
is not alone in this regard. At least in IEEE 802.11 it is also possible
for anyone to upload updates to documents. It has never been a problem.

Donald

-----Original Message-----
From: Spencer Dawkins [mailto:[email-masked]] 
Sent: Thursday, November 29, 2007 3:21 PM
To: Working Group Chairs
Subject: Re: Submitter authorization by ID submission tool

I agree - especially given what the tools team could be working on, if
they 
didn't have to protect us from ourselves on this particular threat...

Spencer

> I spent a few minutes thinking about what we would _do_ to get that
chair 

> How often has this happened with the email submission process we've
used 
> rather than a human-fixes-it solution? At the moment, I don't think
it

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 30 Nov 2007 06:53:48 -0800

RFC  4228 specifies that new versions may be submitted by a previous
author or by a WG chair, and at the time it was felt that anything
more complicated should be handled by the exception process (manual
submission).  The input below seems to confirm that, so I expect we'll
try to get the implementers to confirm to the specification :-)

	Henrik