Re: I-D ACTION:draft-leibzon-responsible-submitter-00.txt (fwd)

On Sun, 2004-10-10 at 15:32, william(at)elan.net wrote:
> On Sun, 10 Oct 2004, Hector Santos wrote:
> 
> > I don't have any conflict of interest issues, in fact, my involvement
> > has been 100% strictly on the technical merits as well as possible
> > legal and social implications of the proposals.  So would it be safe
> > for me to discuss client domain issues and how it relates to
> > SUBMITTER without getting accused of being rude or emotional?
> > The fact is I did have some comments, but when you have others
> > scrutinizing people's input, publicly ostracizing them, why should
> > one even bother?
> 
> You can safely assume that I look at all the comments and appreciate all 
> the input. If I see that somebody has other agenda and is trying to 
> hijack the thread, I do not respond and would not take their comments 
> seriously, but for all other cases I do and appreciate you taking your 
> time to review the proposal and would usually respond to the list or
> to whoever made the comments directly (but it maybe be up to week before
> I respond depending on how much other work I have).
>  
> > There are four key issues with SUBMITTER:
> > 
> > 1) Potential legal user privacy issues with the exposure of user addresses.
> >
> > It would be a major mistake for SMTP developers to open this Pandora Box
> > when there is no technical reason to do so.  See #2
> 
> Currently user emails are exposed in "From", "Sender", "To", "Cc" and most 
> important in "RCPT TO" and "MAIL FROM", none of those have brought privacy
> issues that could not be overcome.  
> 
> Now the exposure during forwarding by submitter is almost certain to be 
> that final recepient would see in submitter the email of original recepient
> of the message (before forwarding) I don't think this too much of the 
> privacy issue. But for those users that do care, the MTA can insert 
> neutral mailbox like "postmaster" instead.
>  
> > 2) Since this is a domain-level authentication scheme, only the domain is
> > required to be exposed. Not the full address.  This will solved #1.
> > 
> > Note: The other possible solution is to use a responsible "postmaster"
> > address to avoid the exposure of user's account addresses that was
> > not introduced by the legitimate user himself.
> 
> All right I agree that it would be usefull to specifically mention
> possibility of using "responsible postmaster" and how it may solve 
> certain privacy concerns. In the next version of the draft I will add 
> paragrapth regading these issues.
> 
> > 3) Responsible domains must change at transition points where the
> > original domain is no longer responsible.
> Clearly this is so.
> 
> > This is a real possibility during deployment where there will be a
> > high degree of heterogeneous systems.  We have seen it in practice
> > where companies "explore" new advanced SMTP systems with new
> > AVS concepts within their existing set or mix of SMTP software.
> > 
> > If it was not addressed it needs to be added to the specs. If it was
> > implied in the spec, it needs clarification.
> 
> This will be addressed and clarified. 
>  
> > 4) Finally, to support SUBMITTER, any client machine domain authentication
> > can not be violated.
> 
> That I do not understand. 
> 
> This is not about client machine, this is about submitter address which 
> in my view more of "network-wide" authentication, i.e. it represents 
> address of the person or entity at particular email network which 
> was responsible for making changes to direction of the message and thus
> is the entity that re-submitted the email message for delivery. The 
> actual machine that added submitter maybe several hops away but that 
> machine would use email address which corresponds to spf record that
> that lists all ip address of other local machines on same network that 
> could potentially be the ones sending email out of the net and to another.
> 
> > This (#4) was pretty much what Doug is pointing out.  The IP must be secured
> > if SUBMITTER is used, hence the machine domain and IP must be secured as
> > well.  In fact, in my own AVS scheme, this sort of mix policy conflict is a
> > trigger for rejection.
> 
> I do not disagree with premises that EHLO name must also be protected and 
> that its bettter to check it before SUBMITTER or MAIL-FROM. In fact if
> you did not read my comments on what needs to be checked and how see:
>  http://archives.listbox.com/[email protected]/200409/0978.html
> 
> But I do disagree that "IP must be secured if SUBMITTER is used", I don't
> see it as prerequisite. Either SMTP Client knows about the ip and considers
> it to be machine on local network (i.e. its agent of the SMTP Client) 
> and then EHLO check does not matter (unless somebody hijacked the space...)
> or we have unknown ip of some server on another network and we can assume
> that server to be an agent of submitter and thus do spf check of submitter
> and expect that ip address to verify.

On point 1 that Hector made, this system must be able to run with an
"open-ended" list without inviting exploits.  This is needed to allow
providers an ability to permit any mailbox address in the messages
sent.  The dual role of using the mail-channel address list as a means
of both authorizing the message and the client unfortunately makes these
open lists attractive for spammers due to unfair accountability.  This
freedom is lost once these open lists become so inundated as to be
unusable.  This also makes for a painful transition and an eventual loss
of freedom.

The use of an address list comes with a substantial risk which
unfortunately is the premise that SPF and Sender-ID use.  The dual use
of this list invites exploits when described as "open-ended" but there
is nothing within the SPF protocol to detect this "open-ended" state. 
Do you understand this problem and do you have a solution?

As related to Submitter, to prevent spoofing and allow the use of
"open-ended" lists, there must be a name that can not be spoofed in this
environment.  This mechanism will likely be needed for at least half a
decade.  There are no headers within the email message that can be
directly authenticated.  Even Submitter exposing these early in the
transaction does not decease the ability to spoof these names in a
partially open environment.  

There is nothing within the SPF protocol draft to ensure exclusion of
repeated label lookups.  A popular version of Bind also makes this
oversight.  The use of a script parser makes this problem worse.  Do you
understand this problem and can you explain how this is overcome?

The grave problems created by the use of address lists with respect to
DNS and network integrity is solved by adopting a name list to describe
the mail-channel.  Financial institutions that are heavily phished, are
not using mailing lists, and have warned their customers about their
messages not able to be forwarded, can close their lists.  The solution,
for "open-ended" list exploitation as well as the DNS and network
related issues, is found by using a name list.  Through the use of a
name list for the mail channel, the lists can remain open for the
majority of users for a smooth transition, and closed when needed.  The
dual use address list is extremely problematic in this area.  Do you
understand the problem and do you have a solution for this?  

The expectations of there being a flag day or some key point where all
lists will suddenly become closed have not confronted issues in this
transition to full compliance.  This compliance is put into greater
doubt should Microsoft spend a decade battling over these issues in
court.  Once these lists are seen as normally being "open-ended," then
the selection of the "accountable name" used in Submitter should be
reconsidered.  A strong name is needed that can be directly
authenticated in order to prove protection against spoofing and
phishing.

-Doug