Re: [Fwd: [Asrg] Re: Documents for LMAP BOF]

On Sat, Feb 07, 2004 at 09:00:19PM -0500, Yakov Shafranovich wrote:
> 
>     http://www.taugh.com/draft-irtf-asrg-lmap-discussion-01.txt


Ok, here are a few comments:

1.1. Summary of the Protocols

   LMAP is based on two concepts: publication of authentication
   data by a domain, and application of that data by a recipient
   MTA.


As you can see from changes in RMX draft, I first called
the mechanism an authentication, later I called it an authorization. 
While the difference is merely philosophical, you should be very
careful to choose correct wording if you want to persist against
professional security researchers. But it is not obvious, whether
this is really authentication or authorization.

You could call it authentication because it answers the question 
"Are you someone@somedomain?" But I don't think that's correct.

Actually, authentication is done by a different mechanism. It is
the TCP sequence number. It authenticates the caller to be the 
one identified by an IP-Address. The IP-Address is the identity, 
not the e-mail address. And you answer the question 
"Is x.x.x.x permitted to use the address someone@somedomain?"

Therefore, I do see that solely as an authorization mechanism, 
which makes use of the implicit TCP authentication. 

(See http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt
why I believe it is important to distinguish between authentication
and authorization.)




   The data published by a domain includes statements as to which
   IP's are permitted to originate mail from the domain in SMTP
   EHLO/HELO and MAIL FROM.

It might be to late to incorporate it into the draft, but you 
should have a look into Microsoft's CallerID draft. They elaborate
how to do this all based solely on header information. I'm not yet
sure whether this works in all cases and whether it is advisable.
But it should be definitely taken into consideration.



   The result is that messages are delivered only when
   all parties consent to their delivery.

This is misleading. Not all MTAs would deny a message immediately
(=before accepting it with an OK to the DATA command). German 
law considers it as a crime if you suppress a message once after it
was entrusted to somone. (which would btw be to late to perform
an LMAP query). I'd write something like "The result is 
that the receiving MTA can deny/reject the message if ..."
And this might sell better, since many people are afraid of 
"false positives". 



   E-mail from LMAP domains that do not publish LMAP data should
   NOT be rejected since there is no requirement that domains do
   so, and many will not, either for policy reasons or from lack
   of resources.  E-email from non-LMAP domains should be treated
   as e-mail is treated today.

Urks. If it is treaded as e-mail is treated today, then it is
treated as spam is treated today. :-(
This means that spammers don't use yahoo, aol, hotmail, but any
other of the millions of domains.

Modify this recommendation, give it a time limit. Should not be
rejected until 1.1.2005 (or any other date). From then it's up to the
receiver whether to accept or reject it. Tell people to be aware 
to risk being blacklisted without an entry then.





2.2. Choice of data to authenticate
   When a message is sent via SMTP, the recipient MTA has a
   variety of items that it could use to authenticate the mail
   sender.  In the order that they are available to the recipient
   MTA they are:

2.2.1 IP address
2.2.2 HELO/EHLO name
2.2.3 Return path
2.2.4 Message header fields
2.2.5 Comparison

   All of these items, IP address, HELO/EHLO argument, return
   path, and message headers, can be used for various kinds of
   authentication.


It strongly disagree, because I believe that the structure of the 
text is wrong. It mixes and confuses things that should be kept
separate:

- There's an IP address. It's an identifier for the party you're 
  talking with. Regarding to what I stated above this is the identity
  of the caller authenticated implicitely by TCP.


- There is an e-mail address/domain name (in fact, there are several,
  the envelope sender, the HELO name, all those in the header like 
  From: Reply-To: Forwarded-By:..., anyone is chosen), which is the 
  resource the caller tries to use. We are going to check whether the 
  caller is permitted to use it. However, this is a completely
  different kind of object than the IP address, and thus should not be 
  mixed with it in the same itemization.

- There is a lookup key used to find the auth record. The idea is to 
  have a function 
  
    f(e-mail-address) -> DNS lookup key

  so the lookup key is derived from the e-mail address (simply by
  cutting away the local part or anything like that).



Therefore I recommend to keep these three classes of identifiers 
strictly separated. That's a matter of security engineering.






3.2.1 SUBMIT (port 587)

I doubt that choosing a different port is a solution to any 
problem. That's security by obscurity.

The reference is missing







4.1. DNS record types

   RMX: defines two new record types, RMX and APL


RMX does not define APL records. They are an RFC on their
own written by someone else.






4.3. Indirect addressing

   RMX: RMX records can refer to RMX and APL records in other
   domains


RMX can refer to PTR/A combinations also.





4.5. Roaming and forwarding support

   RMX: None

Wrong: Support for hostnames, thus allowing DynDNS support
for roaming. Concept of trusted forwarding for forwarding.





5. Privacy Considerations

   This proposal does not examine message contents, or user
   identities in MAIL FROM.  It therefore has no privacy
   considerations which affect those fields.

See http://www.ietf.org/internet-drafts/draft-danisch-scaf-00.txt
for a method to not reveal the structure of your relaying methods
and additional considerations about privacy of end users.





And I'd be happy if RMX would not be listed as just one of many, 
but as the one which was first brought to ASRG (just see the very first
posting) and was the initiator of the whole story, published in Dec
2002. This fact is silently ignored in the references and the text.



regards
Hadmut