Subject: [domainrep] Reputation for initiators of transport connections

From: Pete McCann <[email-masked]>
Date: Mon, 14 Nov 2011 06:39:30 -0500

It seems to me that a reputation service could be used at the transport
layer to reject unwanted connections.  This could help address Doug
Otis' repeated criticisms of DKIM and calls for authenticated SMTP
connections.

There has been discussion on the intarea list about adding identifiers
to connection establishment messages that go through Carrier Grade
NATs so that servers can assign individual reputations to the hosts
behind the NAT.  One of the options being considered is to add a new
TCP option at the middlebox containing a simple integer.

I can imagine generalizing such a feature to use domain names (this
could be related to the name-based sockets idea that has also been
discussed on intarea) and perhaps integration with DANE to provide
authentication of the client connections.

Much of the transport-layer work is out of scope for this group, but
perhaps some discussion of this use case could lead to some cross-WG
activity.

-Pete

---

From: Chris Lewis <[email-masked]>
Date: Mon, 14 Nov 2011 17:11:42 -0500

[!Chair]

> TCP option at the middlebox containing a simple integer.

As I understand Doug's criticism, he's referring to 
real/legit-DKIM-signing MTAs that relay email from infected/unauthorized 
hosts.  Meaning that DKIM can't differentiate between that and legit 
email.  Well of course...

It strikes me that this issue is (at least somewhat) orthogonal to this 
idea with NATs.  Specifically, direct NAT traversal by hosts where a 
transport source identifier might help, are the ones not going thru the 
NAT-owning organization's DKIM-capable MTAs, and are the very 
connections that _won't_ be DKIM signed, or at least, signed with some 
other DKIM credentials and thus subject to reputation evaluation without 
confusion with the netblocks "proper" DKIM.

Secondly, with NATs, there are already many operational mechanisms that 
can be used to deal with this, at least with email.

> authentication of the client connections.

You could probably do this with PAT gateways, taking note of the source 
port.

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 06:18:04 +0800

<Chair>  -- please note that that's in the affirmative.  No bang.

Folks,

> As I understand Doug's criticism, he's referring to real/legit-DKIM-signing MTAs
> that relay email from infected/unauthorized hosts. Meaning that DKIM can't
> differentiate between that and legit email. Well of course...

Doug's line of criticism has nothing to do with the activities in this working 
group.

Discussing the concerns he has so far expressed -- and especially efforts to 
discern their nature and meaning -- cannot possibly be within scope.

Let's focus on work mandated by the charter.

d/

</Chair>

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 06:39:02 +0800

On 11/14/2011 7:39 PM, Pete McCann wrote:
> I can imagine generalizing such a feature to use domain names...

Pete,

Since there is some discussion, here, about annotating the source or context 
from which an identifier's reputation was developed, it is plausible that it 
would be worth considering annotating the context(s) in which it can/should be 
applied.

The slippery slope, here, is probably the danger of moving from discussing or 
specifying /attributes/ about a reputation to specifying /mechanisms/ of use, 
beyond the query mechanism.  Unless I've misread our charter, dealing with usage 
scenarios and mechanisms is outside our charter.

d/

ps.  I've no idea whether I just spoke as a chair.  that probably means I didn't..

-- 

   Dave Crocker

---

From: Pete McCann <[email-masked]>
Date: Mon, 14 Nov 2011 18:32:49 -0500

Hi, Dave,

On Mon, Nov 14, 2011 at 5:39 PM, Dave CROCKER <[email-masked]> wrote:
> would be worth considering annotating the context(s) in which it can/should
> be applied.

Yes, I think it's useful to have some use cases in mind for both developing
and using reputation.  As I understand it, the working group is currently
focused on the e-mail reputation context.  I'm just pointing out that there
might be other, more generally useful contexts for domain reputation.  When
applied at the transport layer, a reputation could help mitigate other kinds of
DoS attacks than just unwanted e-mail.

> The slippery slope, here, is probably the danger of moving from discussing
> or specifying /attributes/ about a reputation to specifying /mechanisms/ of
> use, beyond the query mechanism.  Unless I've misread our charter, dealing
> with usage scenarios and mechanisms is outside our charter.

I think it's just as valid to have an attribute called "opens unwanted transport
connections" as it is to have an attribute like "sends mostly spam".  I agree
that the specific mechanisms of how to associate a domain with a transport
connection, and what to do with a transport connection after a reputation
query has returned an answer, are out of scope for this working group - hence
my suggestion to discuss such matters on intarea or maybe tsvwg.

-Pete

---

From: Dave CROCKER <[email-masked]>
Date: Tue, 15 Nov 2011 08:18:55 +0800

On 11/15/2011 7:32 AM, Pete McCann wrote:
> connections" as it is to have an attribute like "sends mostly spam".

Right.  That is, indeed, the sort of rough equivalence that seemed/seems to me 
to justify the "attribute" line of your suggestion within the group's charter.

d/
-- 

   Dave Crocker