Subject: Point of Order: Incomplete, flawed response to MARID WG Charter

From: "Chris Haynes" <[email-masked]>
Date: Wed, 18 Aug 2004 11:32:14 +0100

Point of order
======

May I humbly raise a point of order to the Chair concerning the projected output
of the MARID WG?

The WG is chartered to produce solutions which "confirm that peer MTA's actions
are authorized by specific domains or networks."

I also note the WG's intention to proceed to 'last call' on Sender-ID within a
few days.

Is it in order for the WG to proceed to last call with a solution which:
-  addresses only half the problem space and
-  increases the number of unauthorized, frequently virus-carrying, messages
   on the Internet?

Chris Haynes
~~~~~~~~~~~~~~~~~~~-

Basis and explanation of the Point of Order:
======

Within the scope of SMTP there are two distinct message types: For brevity I'll
term them 'Original' and 'Bounce'.

With Sender-ID the WG has produced a method for Original messages to be
authorized.

The WG has not yet produced a method for Bounce messages to be authorized.

It has therefore not yet provided a solution for the second half of the problem
space.

Furthermore...

If the Sender-ID authorisation test fails (core-03, section 5.3) the receiving
MTA will return a '550' response to the client MTA, containing further
information about the rejection.

The client will, in most cases, generate and send a Bounce message containing
this rejection information, and it is common practice to include a copy of the
Original message within that Bounce.

Therefore, Sender-ID _requires_ MTAs of previous good repute to generate and
send Bounce messages which:

- Are themselves wholly unauthorised,

- Use information from an Original which is _known_ to be unauthorized,

- May be sent to a destination wholly unrelated to the sender of the Original,

- May contain malicious content copied from that Original unauthorized message.

In essence...
Sender-ID requires a peer MTA to perform the act of sending a message when it is
_known_ that no domain or network has authorized that action.

This is in clear conflict with the WG's own Charter.

~~~~~~~~~~~~~~~~~~~-

PR effect of the current proposal:
======

Just to illustrate the weakness of the current WG proposal, I postulate some
press headlines which, in my opinion, would be technologically accurate:

"<dominant vendor>'s anti-spam scheme backfires - leads to more virus-carrying
messages on Internet"

"IETF chooses <dominant vendor>'s patented,  incomplete, flawed approach -
ignores proven solution offered by Open Source community, "

"<dominant vendor> makes another security blunder - and this time takes the IETF
with it!"

Maybe this last headline is not entirely accurate. I'm not sure that promoting
the (avoidable)  propagation of viruses is strictly a 'security' issue, but that
would not stop the press using such an eye-catching 'angle'.

~~~~~~~~~~~~~~~~~~~--

---

From: Andrew Newton <[email-masked]>
Date: Wed, 18 Aug 2004 09:27:00 -0400

> May I humbly raise a point of order to the Chair concerning the 

I'm not sure there is much humility in raising a point of order 
premised on your opinion of the technical proposal and not on the 
process for how this group is conducting its work.

Or perhaps you and I have a different idea for the meaning of point of 
order.

You are certainly free to express your technical opinion regarding 
Sender ID, but let's not start using process issues to win technical 
arguments.

BTW, your technical objections to Sender ID are noted.

-andy

---

From: Dean Anderson <[email-masked]>
Date: Wed, 18 Aug 2004 10:24:26 -0400 (EDT)

A point of order is a process check. The process is not supposed to move
forward until the technical issues are solved. If the technical issues
aren't solved, then the process shouldn't move forward until they are.  
So, a technical opinion that the technical problems aren't solved can
certainly form the basis for a process question.

I submit that your next step as working group chair is to obtain a
technical consensus on the question raised by Mr. Haynes.  If he is right,
then the process shouldn't move forward yet.

However, I'd say he has raised a good point. Though, I'd say my 9 or 10 
points are also significant show-stopper problems.

		--Dean

---

From: Marshall Rose <[email-masked]>
Date: Wed, 18 Aug 2004 08:04:49 -0700

> May I humbly raise a point of order to the Chair concerning the 

in brief: no.

there are no points of order in the ietf process. there is no roberts 
rules of order. there are no senate rules of filibuster. i could go on, 
but people familiar with the ietf process, should have already gotten 
the point.

if you have specific technical criticisms as to the document, make them 
in a concise and clear fashion.

you may continue to do so until the duration of the working group last 
call when the chairs will call for consensus.

if you are unhappy with this process, then you should appeal directly 
to the AD, the IESG, the IAB, etc., as put forth in the documents that 
describe the ietf process.

/mtr

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 18 Aug 2004 09:15:40 -0700

> -  increases the number of unauthorized, frequently virus-carrying, messages

Yes, this is in order for that WG, while I absolutely share your 
concerns (and therefore had designed RMX to deal with the bounce
message problem, so there was a solution to that problem, but that
WG does not want this problem to be solved).

Security protocol design requires to define a problem space, to create
a solution, and then to show that the solution actually solves the
problems of the problem space. That's not the way this WG works.

The space this WG is working on, is the commercial interestes
space. And that's what's going to be fulfilled. Interestingly, this 
space is not well-defined. As soon as you mention or question it,
you'll get kicked out from the mailing list.

So don't expect the output of the WG to be a good solution to a
technical security problem, because that's not what it has been 
engineered to be. If it had been, you would have found a precise
definition of the 'problem space', what the protocol is aimed to 
solve.

Have a look at the 'Goales and Milestones' section of the group
charter. Do you find any precise description or definition of the kind
of attack this WG is working on? No. That's not the way it works.

regards
Hadmut