Subject: RE: [Asrg] Email Address Verification Notes (fwd)

From: "Eric D. Williams" <[email-masked]>
Date: Wed, 2 Apr 2003 18:32:03 -0500

William,

Thanks again.  I am reviewing the presentation you presented, and although I am 
not finished I think I detect a different approach to analyzing proposals 
(though not fatal, and as I said I am not finished a complete review) in your 
presentation.  For example the analysis of the 'IP of mail sender' drafts.

From what I understand of the methodology it would not be limited to MAIL FROM: 
(recognize I am talking about the method not protocol conformance).  The goal 
is to authenticate the authorization to act as an originating MTA for a domain, 
however I see at least two methods for testing the validity of that method.

1) Receiving MTA performs a DNS query on the connecting/originating IP for the 
appropriate resource record to determine authorization for SMTP origination for 
the domain involved (the domain is determined by either MAIL FROM: OR From:, 
or;
2) Receiving MTA performs a DNS query on the connecting/originating IP for the 
appropriate resource record to determine authorization for SMTP origination for 
the domain involved (the domain is determined by either MAIL FROM: AND From:.

These are fundamentally different in effect though they use the same 
methodology.  In your example you analyzed the approach #1 only.  Respectfully, 
my reading (and not yours) does not use the same approach for any of the 
proposals yet I am satisfied that your approach is valid and bears out the 
results you concluded.

Using my approach (step 1) I first strip the proposal, unless it is of a 
protocol implementation, of all of the transport baggage, in this case 
SMTP/ESMTP enveloping failures and RFC822 header forge-ability.  Then (step 2) 
abstract the proposal to it's essence (core functionality), in this case 
'authentication of authorization as an SMTP originator'.  The next step (step 
3) analyzes the scope of the proposed solution, in this case RR via DNS.

At that step I have determined a hurdle for this proposal, on origination SMTP 
MUAs (as we see them) should always be allowed by a local server.  But I don't 
discern a mechanism to establish that relationship, not a fatal flaw, but one 
that can introduce a loophole or worse overhead in the core of the scope (DNS). 
 If in fact every client connection must be verified (Con). I also notice that 
the proposed method does not require a lot of transactions to make the 
fundamental determination e.g. can this IP send messages into the MTS (Pro). 
 Conclusion the proposal has scoping issues.

This represents a higher level analysis of the methodology (authentication of 
authorization) as opposed to your deeper analysis of each of the proposals 
vulnerabilities to subversion.  Usually scoping issues such as this can be 
fixed by either simplification or complexity, the decision is up to the author 
I guess.  The current requirement is that the proposal be easy to use, but  it 
does not have to be simple.

I think in general that this type of approach may be promising on that basis. 
 I would appear that a plausible implementation of this component (which is not 
a full solution I think) would only verify whether the connecting MTA was 
authorized as an SMTP originator, and nothing else (simplification).  Other 
issues such as DNS vulnerabilities are not pertinent to that analysis (though 
it could be an impact on an implementation that did not consider those risks).

I know you did a lot more than a cursory analysis and it is well done, it just 
occurred to me that there are different ways these proposals may be analyzed. 
 Hopefully, an alternative method (for this 'researchy' group) of evaluation 
will allow a little more thoughtful scrutiny of the proposals moving forward 
and a little latitude for the author to alter the proposals method or premise 
to derive a better result.

my $.02

-e

On Wednesday, April 02, 2003 12:05 PM, [email-masked] [SMTP:[email-masked]] 
wrote:
> I'm reforwarding my email verification notes. For some reason they do not
> appear in the archive for my original post (anybody know why this happens?
> https://www1.ietf.org/mail-archive/working-groups/asrg/current/msg01246.html)
> The notes were also used in the presentation at:
> http://www.elan.net/~william/asrg-emailpathverification-presentation.pdf
> To a degree I need this post, so it goes to archive (so I could reference
> it in the summary I'm working on).
>
> ---------- Forwarded message ----------
> Date: Wed, 12 Mar 2003 01:59:32 -0800 (PST)
> From: [email-masked]
> To: ASRG <[email-masked]>
> Subject: Email Address Verification Notes
8<...snipped to save bandwidth...>8
> ----
> William Leibzon
> Elan Communications Inc
> [email-masked]
>
> _______________________________________________
> Asrg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/asrg
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: [email-masked]
Date: Thu, 3 Apr 2003 01:00:49 -0800 (PST)

I'm not advocating either #1 or #2 from your list below in either the 
presentation or notes - both are just the basic or summary of some
non-crypto source-authentication approaches but not speciying exact details.

As far as my proposal it'd be a lot more complex and mail tracking with 
dns would be just one component of it (one of about 8 drafts) and I'n not 
advocating use of either envelope "MAIL FROM" or header "From", I'd rather 
actually create new header for authenticated sender and only when this new 
header is absent then heder "From:" can be used. But envelope "MAIL FROM" 
is changeble for in-between mail servers (maillists, forwarders) and hence 
it should be used on per-transaction authentication (where as header "From"
be be used in authentication the source). When I find time to write all these 
drafts, I guess you will see what I mean - right now I'v presented bits 
and pieces and it may seem like there are scope issues, overall I 
think this is eliminated (I guess by introducing more complexity...).

And I (and I'm sure other members of reseach group too) would more then 
welcome differentanalysis approaches. In fact at some point we will need 
to come with list of what and how needs to be analyzed and then have it 
done for each proposal and having different parallel analysis done would 
be quite usefull. So it maybe good idea to write out more specs on how you 
would analyze a proposasl, though having requirement is often necessary in 
order to do it.

> William,
> 
> Thanks again.  I am reviewing the presentation you presented, and 
> although I am  not finished I think I detect a different approach to 
> nalyzing proposals (though not fatal, and as I said I am not finished a 
> complete review) in your presentation.  For example the analysis of the 
> 'IP of mail sender' drafts.
> 
>>From what I understand of the methodology it would not be limited to 
> MAIL FROM: (recognize I am talking about the method not protocol 
> conformance). The goal is to authenticate the authorization to act as 
> an originating MTA for a domain, however I see at least two methods for 
> testing the validity of that method.
> 
> 1) Receiving MTA performs a DNS query on the connecting/originating IP 
> for the appropriate resource record to determine authorization for SMTP 
> origination for the domain involved (the domain is determined by either 
> MAIL FROM: OR From:, 
> or;
> 2) Receiving MTA performs a DNS query on the connecting/originating IP 
> for the appropriate resource record to determine authorization for SMTP 
> origination for the domain involved (the domain is determined by either 
> MAIL FROM: AND From:.
> 
> methodology.  In your example you analyzed the approach #1 only.  
> Respectfully, my reading (and not yours) does not use the same approach 
> for any of the proposals yet I am satisfied that your approach is valid 
> and bears out the results you concluded.
> 
> SMTP/ESMTP enveloping failures and RFC822 header forge-ability.  Then 
( step 2) abstract the proposal to it's essence (core functionality), in 
> this case 'authentication of authorization as an SMTP originator'.  The 
> next step (step 3) analyzes the scope of the proposed solution, in this 
> case RR via DNS.
> 
> At that step I have determined a hurdle for this proposal, on 
> origination SMTP MUAs (as we see them) should always be allowed by a 
> local server.  But I don't discern a mechanism to establish that 
> relationship, not a fatal flaw, but one that can introduce a loophole 
> or worse overhead in the core of the scope (DNS).  If in fact every 
> client connection must be verified (Con). I also notice that the 
> proposed method does not require a lot of transactions to make the 
> fundamental determination e.g. can this IP send messages into the MTS 
> (Pro). Conclusion the proposal has scoping issues.
> 
> This represents a higher level analysis of the methodology (authentication
> of authorization) as opposed to your deeper analysis of each of the 
> proposals  vulnerabilities to subversion.  Usually scoping issues such 
> as this can be fixed by either simplification or complexity, the 
> decision is up to the author I guess.  The current requirement is that 
> the proposal be easy to use, but it does not have to be simple.
> 
> I would appear that a plausible implementation of this component (which 
> is not a full solution I think) would only verify whether the connecting
> MTA was authorized as an SMTP originator, and nothing else (simplification). 
> Other issues such as DNS vulnerabilities are not pertinent to that 
> analysis (though it could be an impact on an implementation that did not 
> consider those risks).
> 
> I know you did a lot more than a cursory analysis and it is well done,
> it just  occurred to me that there are different ways these proposals 
> may be analyzed.  Hopefully, an alternative method (for this 'researchy'
> group) of evaluation will allow a little more thoughtful scrutiny of 
> the proposals moving forward and a little latitude for the author to 
> alter the proposals method or premise to derive a better result.
> 
> my $.02
> 
> -e
>