Subject: Working Group Last Call on Sender ID documents

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Aug 2004 10:53:00 -0400

Today begins a 2 week working group last call for the following 
documents:
   draft-ietf-marid-core-03.txt
   draft-ietf-marid-submitter-03.txt
   draft-ietf-marid-protocol-02
   draft-ietf-marid-pra-00.txt

To better facilitate discourse, we ask all working group participants 
to abide by the following parameters:

1) Messages concerning this last call should fall into one of four 
categories: document bugs, technical errors, technical omissions, or 
implementation and deployment issues.  Each subject line must be 
prefaced with a designation stating the category into which it falls.  
These designations are "DOC-BUG", "TECH-ERROR", "TECH-OMISSION", and 
"DEPLOY".

e.g.,

   Subject:  DOC-BUG: typos in -core

The co-chairs will not take into consideration messages that do not 
meet these criteria.  Here are the descriptions of the categories:

   DOC-BUG: Document bugs relate to simple errors within the document, 
such as typos, bad ABNF, etc...  All messages in this category should 
be subject prefaced with "DOC-BUG".  The author of the message should 
note the document bug and provide corrective text.

   TECH-ERROR: Technical errors are misuses of technical mechanisms 
specified in the document.  All messages in this category should be 
subject prefaced with "TECH-ERROR".  The author of the message should 
note the technical error and supply a fix if possible.

   TECH-OMISSION: Technical omissions are issues surrounding lack of 
needed functionality.  An example would be failure to guard against 
replay attacks when using cryptographic hashes, etc...  All messages in 
this category should be subject prefaced with "TECH-OMISSION".  The 
author of the message should clearly note 1) the goal of the mechanism 
lacking the necessary feature, 2) the purpose of the necessary feature, 
and 3) a suggested fix to include such a feature while still adhering 
to the stated gaol of 1.

   DEPLOY: Implementation and deployment issues relate to both technical 
and non-technical barriers for the implementation and deployment of the 
specifications described in these documents.  All messages in this 
category should be subject prefaced with "DEPLOY".  The author of the 
message should clearly state why he/she will personally not be able to 
implement or deploy a specification.  The author of the message should 
not speak on behalf of others.  Inclusion of citations supporting a 
position will also be helpful: for technical concerns these should be 
citations to research or studies, for IPR concerns these should be 
citations to legal filings.

2) Discussions of the validity for the need of any MARID solution or 
the need for a MARID working group are not appropriate at this time.  
While these opinions may be valid, they should be discussed with the 
IESG as an appeal for chartering this working group.  It is now the job 
of this working group to finish the work under its charter and not 
debate the validity of the charter.

-MARID Co-chairs

---

From: John Leslie <[email-masked]>
Date: Mon, 23 Aug 2004 13:24:20 -0400

Andrew Newton <[email-masked]> wrote:
> implementation and deployment issues...

   Does this mean that comments posted before today must be repeated?

--
John Leslie <[email-masked]>

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Aug 2004 13:40:55 -0400

> Does this mean that comments posted before today must be repeated?

If you have not received explicit acknowledgment from the draft authors 
or co-chairs that changes will be made due to your input, then I 
suggest reposting.

-andy

---

From: "John Glube" <[email-masked]>
Date: Mon, 23 Aug 2004 15:07:26 -0400

Marshall,

I probably should have asked this question sooner.

On August 6, concerning short term milestones, you wrote:

>3. final ipr statements are due monday, august 23rd.

>4. working group last call on the revised documents begins
>monday, august 23rd. the co-chairs will be sending out a
>separate email on this topic closer to this date.

http://www.imc.org/ietf-mxcomp/mail-archive/msg03046.html

In response to a follow up question, Andy wrote:

>To belay any fears, Aug 23 is a hard and fast deadline.

http://www.imc.org/ietf-mxcomp/mail-archive/msg03060.html

By stating:

>final ipr statements are due monday, august 23rd:

* What time zone does one use?

* Did this mean by Monday, August 23, 2004 so that
statements would have to be filed by midnight, Sunday,
August 22, 2004 or on Monday, August 23, 2004 so that
statements would have to be filed by midnight of today, or
such other time frame on either of these dates as the
Chairs may indicate?

I apologize for being picky, however since much has been
made of this deadline, I am simply asking for the record to
be clear.

John

P.S. Also, since we are in last call and any license
requirements may have a bearing on implementation issues,
could you ask that the full notice of any filings also be
sent to this list, so that all can be made aware of any
statements made?

cc. Andy Newton 

John Glube
Toronto, Canada
 
The FTC Calls For Sender Authentication
http://www.learnsteps4profit.com/dne.html

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Leslie
Sent: August 23, 2004 1:24 PM
To: Andrew Newton
Cc: IETF MARID WG; Marshall Rose
Subject: Re: Working Group Last Call on Sender ID documents

> implementation and deployment issues...

   Does this mean that comments posted before today must be
repeated?

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.737 / Virus Database: 491 - Release Date: 11/08/2004

---

From: Andrew Newton <[email-masked]>
Date: Mon, 23 Aug 2004 16:19:48 -0400

On Aug 23, 2004, at 4:16 PM, Daniel Quinlan wrote:

> Do you prefer for similarly designated issues ("DOC-BUG", etc.) for a
> particular document ("-core", etc.) to be bundled in a single email or
> for each issue be submitted in a separate message?  (I'm assuming
> related issues should be in a single message even if separate sections
> of the document are affected.)

Doing them separately helps us keep track of the issues.

Thanks.

-andy

---

From: Daniel Quinlan <[email-masked]>
Date: 23 Aug 2004 13:16:34 -0700

Daniel

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Marshall Rose <[email-masked]>
Date: Tue, 24 Aug 2004 14:58:31 +0100

> I probably should have asked this question sooner.

alternatively, you could have waited 12 hours and 29 minutes, and then 
you wouldn't have had to ask your question at all.

given the posts from harry katz around midnight, your message appears 
moot.

/mtr

---

From: Matthew Elvey <[email-masked]>
Date: Tue, 24 Aug 2004 20:05:52 -0700

There are some problematic issues regarding my possible Sender ID 
deployment that I'd like to (re-)raise.
I wish I had more time to research and polish this post and participate 
more, but I'm leaving for nearly 2 weeks tomorrow AM.

My second and third points are more or less 'me too' comments, but my 
first one is extremely important and underexposed.

1)A good fraction (I'd estimate 1/2) of my end users have their MTAs 
configured to send through several SMTP servers, using different 
From:'s.  (I send through several, myself. About 1/4 of my users have 
more than one MTA.)  We will have to somehow discover each of my users 
SMTP configurations, the Sender ID configurations for the From:'s they 
use, and figure out if there's a way for them to continue to use those 
From:'s, and walk them through configuring their MTAs to use the SMTP 
servers that will allow them to use those From:'s.  If Sender ID had 
embraced Unified SPF, in particular: a mandatory HELO check, the checks 
on HELO would be able to tie to a reputation often enough that an end 
user using an SMTP server not authorized for their From: would be an 
occasional issue, instead of an overwhelming support issue.  The SMTP 
servers used by my end users would have good enough reputations that the 
PRA check would be unnecessary, and the message would get through even 
if the server didn't support SUBMITTER and was used by a mobile/guest 
user using their usual domain.  The PRA checks would not fail because 
they would not be run.  Setting up user.[remote|mobile]-users (the 
example of which I'm unable to grok) won't be necessary.  I have made 
these points before; see 
http://asrg.sp.am/wiki?Client_SMTP_Validation#Advocacy .   This change 
(a mandatory HELO check) would make MARID work well with ORDERS OF 
MAGNITUDE less work.  I was expecting to see this change in this 
proposal set, as it seemed to meet with little resistance, and was in 
Unified SPF, and getting serious support from key players.  I wonder if 
folks are happy to make it close to mandatory for everyone to upgrade 
their MTAs.  (In addition, Sender ID appears to require that all _MUAs_ 
be updated to show the PRA, for full effectiveness.)  No real downside 
to mandatory HELO checks (using the pass/fail/continue logic of Unified 
SPF) has been presented to date.

Phrased differently:
Sender ID fails to be a solution that only requires sysadmin action; it 
mandates end-user reconfiguration on a massive scale, because, IIRC, it 
doesn't say that HELO checking should/must be done.  Hence I (of 
elvey.com) would have to get all my domain's end users to use MSAs that 
I (as DNS admin of elvey.com) knew about.  For fastmail.fm, my email 
provider, who hosts mail for thousands of domains, they would have to 
support this for each user of each domain!)  If HELO checking is 
mandatory, they just send HELO fastmail.fm, and ensure that fastmail.fm 
has a good reputation.

2)IP.  The Microsoft IP is encumbered, therefore, as others pointed out 
in threads like "DEPLOY: Microsoft Patent license unworkable with GPLed 
MTAs", I'll have trouble using, e.g. debian and Sender ID.  Microsoft 
has belligerently refused to make the changes that it has been made 
clear are a problem.  I say belligerently not to poke at Microsoft, but 
because their statement in Q7 of their Sender ID IP FAQ is belligerent.  
It's been said that only individuals are members of the IETF, and that 
is certainly true, but that in NO way implies that an individual who is 
paid by and managed by a company to participate in the IETF must not be 
considered to represent that company; no IETF policy suggests that the 
interests of an individual's employer are not relevant to discussion.

3)DDoS vulnerability.  (~-protocol, Section 6.2)

I find the spec acceptable as is in this regard, but think it could be improved.  10 evaluations of check_host() could result in >> 100 DNS queries, a significant amplification, yes?  
I think the DNS queries are the expensive part of the calculation, and the limit should be on the # of DNS queries.

=-=-=-=--=-=

Another TYPO in -protocol-02
s/than one strings./than one string./

I like the way that the wildcard and TXT RR situations have been 
handled.  The Sender ID drafts have come a long way (I considered them 
hopeless when I first read 'em and almost didn't send in my 
suggestions!) but there's a ways to go.

Out of time.  Thanks for reading.