Subject: Re: Last Call: <draft-kucherawy-marf-source-ports-03.txt> (Source Ports in ARF Reports) to Proposed Standard

From: Scott Kitterman <[email-masked]>
Date: Mon, 07 May 2012 18:35:11 -0400

On Monday, May 07, 2012 12:50:25 PM The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> - 'Source Ports in ARF Reports'
>   <draft-kucherawy-marf-source-ports-03.txt> as Proposed Standard
...

I think adding the source port field has value, particularly for abuse 
reporting, but I think making it RECOMMENDED for authentication failure 
reporting is not appropriate.

The last two paragraphs of section three read (trivial typo - there's an extra 
new line in the first paragraph that I removed here):

   When any report is generated that includes the "Source-IP" reporting
   field (see Section 3.2 of [ARF]), this field SHOULD also be present,
   unless the port number is unavailable.

   Use of this field is RECOMMENED for reports generated per
   [AUTHFAILURE-REPORT] (see Section 3.1 of that document).

The first corresponds to use in abuse reporting.  As described in this draft 
and the references, I think the addition of source ports for abuse reports is 
well justified.  OTOH, if you look at Section 3.1 of RFC 6591  [AUTHFAILURE-
REPORT], it gives the purpose of the most of the various data elements it 
RECOMMENDS as "to aid in diagnosing the authentication failure."

I'm not aware of any authentication methods supported by RFC 6591  
[AUTHFAILURE-REPORT] where source port makes a difference in authentication 
results.  If RFC 6591 is extended in the future to include one that does, that 
would be the time to make source port RECOMMENDED for authentication failure 
reports.  In the mean time it's just additional overhead and message size.

My suggestion would be to change the last part of section three to read:

   When any authentication failure report [AUTHFAILURE-REPORT] is generated
   that includes the "Source-IP" reporting field (see Section 3.1 of
   [AUTHFAILURE-REPORT]]), this field MAY also be included.

Other than that, I think it's ready to go.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 07 May 2012 17:59:49 -0700

On 5/7/12 3:35 PM, Scott Kitterman wrote:
> > The IESG has received a request from an individual submitter to
> > consider the following document: - 'Source Ports in ARF Reports'
>  I think adding the source port field has value, particularly for
>  abuse reporting, but I think making it RECOMMENDED for authentication
>  failure reporting is not appropriate.
>
>  The last two paragraphs of section three read (trivial typo - there's
>  an extra new line in the first paragraph that I removed here):
>
>  The first corresponds to use in abuse reporting. As described in
>  this draft and the references, I think the addition of source ports
>  for abuse reports is well justified. OTOH, if you look at Section
>  3.1 of RFC 6591 [AUTHFAILURE- REPORT], it gives the purpose of the
>  most of the various data elements it RECOMMENDS as "to aid in
>  diagnosing the authentication failure."
>
>  [AUTHFAILURE-REPORT] where source port makes a difference in
>  authentication results. If RFC 6591 is extended in the future to
>  include one that does, that would be the time to make source port
>  RECOMMENDED for authentication failure reports. In the mean time
>  it's just additional overhead and message size.
>
>  When any authentication failure report [AUTHFAILURE-REPORT] is
>  generated that includes the "Source-IP" reporting field (see Section
>  3.1 of [AUTHFAILURE-REPORT]]), this field MAY also be included.
>
Dear Scott,

Agreed.  Logging ports translated by LSNs is not recommended.  The only 
tangible data represents the source IP address made available by LSN 
services.  Both of which touch upon the changes you recommend.   At some 
point, authentication reporting also needs to be updated as well.

Regards,
Douglas Otis

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 May 2012 04:20:00 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott Kitterman
> Sent: Monday, May 07, 2012 3:35 PM
> To: [email-masked]
> Subject: Re: Last Call: <draft-kucherawy-marf-source-ports-03.txt> (Source Ports in ARF Reports) to Proposed Standard
> 

If all one is doing is figuring out why something like a DKIM signature failed on an otherwise legitimate message, then I agree the source port isn't a useful input to that work.  In fact, as far as DKIM goes, the source IP address is probably not useful either.

If, however, one is trying to track down the transmission of fraudulent email such as phishing attacks, source ports can be used to identify the perpetrator more precisely when compared to logs.  Support for this latter use case is why I believe RECOMMENDED is appropriate.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 May 2012 00:49:09 -0500

"Murray S. Kucherawy" <[email-masked]> wrote:

>> Subject: Re: Last Call: <draft-kucherawy-marf-source-ports-03.txt>
>(Source Ports in ARF Reports) to Proposed Standard
>> 
>generated
>If all one is doing is figuring out why something like a DKIM signature
>failed on an otherwise legitimate message, then I agree the source port
>isn't a useful input to that work.  In fact, as far as DKIM goes, the
>source IP address is probably not useful either.
>
>If, however, one is trying to track down the transmission of fraudulent
>email such as phishing attacks, source ports can be used to identify
>the perpetrator more precisely when compared to logs.  Support for this
>latter use case is why I believe RECOMMENDED is appropriate.

Which is exactly the case (abuse report) the second to last paragraph takes care of.  I agree RECOMMENDED is appropriate there and you have it there.

For auth failure analysis I read you as agreeing it's not needed.  There are some authorization methods that use IP address, so I don't think that for auth failure reports inclusion of IP address and source port are comparable.

Based on your response, I don't understand your objection to dropping the RECOMMENDS for auth failure reports and keeping it  for abuse reports?

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 8 May 2012 06:23:46 +0000

> Sent: Monday, May 07, 2012 10:49 PM
> To: [email-masked]
> Subject: RE: Last Call: <draft-kucherawy-marf-source-ports-03.txt> (Source Ports in ARF Reports) to Proposed Standard
> 
> Which is exactly the case (abuse report) the second to last paragraph
> takes care of.  I agree RECOMMENDED is appropriate there and you have
> it there.
> 
> For auth failure analysis I read you as agreeing it's not needed.
> There are some authorization methods that use IP address, so I don't
> think that for auth failure reports inclusion of IP address and source
> port are comparable.
> 
> Based on your response, I don't understand your objection to dropping
> the RECOMMENDS for auth failure reports and keeping it  for abuse
> reports?

I don't think it's possible for software to identify correctly a case of an accidental authentication failure versus detected fraud.  If it were, then I'd agree that for the simple authentication failure case the source port isn't useful.

In the absence of that capability, isn't it better to give the investigating user as much information as possible to use in correlation of logs and such?

-MSK

---

From: Douglas Otis <[email-masked]>
Date: Tue, 08 May 2012 08:08:25 -0700

On 5/7/12 11:23 PM, Murray S. Kucherawy wrote:
>> Subject: RE: Last Call:<draft-kucherawy-marf-source-ports-03.txt>  (Source Ports in ARF Reports) to Proposed Standard
>>
Dear Murray,

This is not about individual submissions or retaining privacy.  This is 
about retaining the only (weakly) authenticated piece of information 
within public SMTP exchanges.  All other SMTP elements are easily 
spoofed and worthless at positively identifying compromised systems for 
the purpose of subsequent isolation.   Attempts to track ports in the 
presence of LSN overlooks the highly transitory translations.  However, 
the LSN scheme provides a means to determine the source IP address.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 May 2012 22:04:30 -0400

> > To: [email-masked]
> > Subject: RE: Last Call: <draft-kucherawy-marf-source-ports-03.txt> (Source
> > Ports in ARF Reports) to Proposed Standard
 
> I don't think it's possible for software to identify correctly a case of an
> accidental authentication failure versus detected fraud.  If it were, then
> I'd agree that for the simple authentication failure case the source port
> isn't useful.
 
Then why did we bother with a separate type or report for authentication 
failure?  Presumably we believe systems can have criteria for "I'm sending 
this because the message is abusive" versus "I'm sending this because it 
failed $authentication_type".

> In the absence of that capability, isn't it better to give the investigating
> user as much information as possible to use in correlation of logs and
> such?

Personally, in the forensic work I've done I've found things like mail queue 
IDs a lot more important than source port.  There is lots of information that 
would be useful for an investigation.  On this basis, I could see MAY include 
source port on auth failure reports, but I think making it RECOMMENDED on the 
basis of it may be useful is justified.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 9 May 2012 03:14:08 +0000

> Sent: Tuesday, May 08, 2012 7:05 PM
> To: [email-masked]
> > In the absence of that capability, isn't it better to give the
> > investigating user as much information as possible to use in
> > correlation of logs and such?
> 
> Personally, in the forensic work I've done I've found things like mail
> queue IDs a lot more important than source port.  There is lots of
> information that would be useful for an investigation.  On this basis,
> I could see MAY include source port on auth failure reports, but I
> think making it RECOMMENDED on the basis of it may be useful is
> justified.

If a spam bot connects to your MTA and sends a message in, the only queue ID you have is the one your own MTA generated.  How will that be useful tracing the spam back to the very machine that generated it?

RFC6302 talks about why this is important a lot more than this document does.

-MSK