Subject: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues)

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Oct 2011 08:07:22 +0200

On 25 October 2011 13:26, Murray S. Kucherawy wrote:

> Have you read the drafts that are out already?

I looked into something and got the vague idea that
Dave wants percent values instead of simple YES / NO
answers.  That does not exclude "DNS based lists" as
defined in RFC 5782.  [[Keith Moore offered a nice
flame war about 'DNSBL' and RFC 5782 on the SMTP list
recently, but I wasn't in the mood to follow suit.]]

Just in case, DNSBLs as defined in RFC 5782 are "DNS
based lists", not necessarily black/block/white/...

In essence RFC 5782 specifies a way how DNS can be
used to encode any kind of reply with up to 23 bits
as (pseudo-) IPv4 in the range 127.0.0.0/8 excluding
127.0.0.1/32.

Looking in your I-D.*-identity.01 you apparently have
that as RFCxxxx+3.  IOW, where you can get way with
0.00, 0.01, ..., 0.99, 1.00 for RATING this could be
encoded in 7 bits for 0..100 in RFCxxxx+3.  You'd end
up with 16 available bits x+y in 127.x.y.z for other
stuff such as RATER-AUTHENTICITY.

Syntax nit for the media type:  Please get rid of the
case-sensitive ABNF; nobody uses this (unless they MUST); there might
be even some BCP about using case-insensitive syntax whenever
possible.  You can still
use upper-case for readability.

Admittedly DNSBLs can't help you if you want info in
the direction of RATER or SAMPLE-SIZE.  And if you'd
encode ASSERTION values as bits you'd need a kind of
"enumeration registry" with defined ASSERTION values
for whatever you intend to enumerate.

Semantical nit in I-D.*-vocab.01:  If you have a term
MAILFROM it is almost certainly pointless to create
a different term SPF.  Details for folks not familiar
with SPF:  SPF can be used to check the SMTP "HELO",
that is an ordinary host-name or a "domain-literal"
(= IP in square brackets) of the "client", i.e., the
SMTP sending mail.

SPF can also check the "MAIL FROM", that used to be
the Return-Path in RFC 821, and today (2821+5321) it
is also known as "envelope sender address"; the path
business is mostly historic (and removed if present
in SPF checks).

There is one special case where the "return path"
still is (syntactically) a path, the "MAIL FROM" can
be empty; notably in "delivery status notifications"
(DSNs) not limited to "non-delivery reports" (NDRs,
also known as bounces) for obvious reasons.

In SPF checks this empty path is mapped to a pseudo-
address postmaster@helo-domain, where "helo-domain"
is simply the host-name (or domain-literal) as seen
in the HELO check.  In other words, for the purposes
of SPF the reputation of HELO domain example and the
reputation of MAIL FROM postmaster@example are the
same thing.

The MAILFROM identity in I-D.*vocab-identity should
be exactly what RFC 4408 and 4408bis say.  It makes
no sense to use a different term SPF, because there
is no meaningful "reputation" for an empty string in
MAIL FROM: <>

One of the better SPF features (once you get past its
various obscure and baroque features), it is strictly
built on SMTP, forward, sideward, backward.  And DKIM
is strictly SMTP-agnostic, DKIM could handle NNTP or
avian carrier if desired.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Oct 2011 01:54:53 -0700

> -----Original Message-----
> From: Frank Ellermann [mailto:[email-masked]]
> Sent: Tuesday, October 25, 2011 11:07 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: I-D.*-reputation-*.01 (was: A document about reputation data meta-issues)
> 

All true, but the IESG made it clear they don't intend to allow A record overloading to become a standard.

We're also considering allowing negative ratings (see other thread).

> be even some BCP about using case-insensitive syntax whenever possible.
> You can still use upper-case for readability.

Yeah, that's probably fair.

> (= IP in square brackets) of the "client", i.e., the

That's not true.  You might develop reputation based on SMTP MAIL FROM without checking SPF.  (Might be a dumb idea, but you could do it.)

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Oct 2011 11:23:32 +0200

On 26 October 2011 10:54, Murray S. Kucherawy wrote:

 [RFC 5287]
> All true, but the IESG made it clear they don't
> intend to allow A record overloading to become a
> standard.

Pointer, please.  The IESG is supposed to determine
the IETF consensus, and I'm not aware of any IETF
consensus wrt using DNS as a kind of "23-bits whois":
For this purpose UDP is cheaper than TCP, isn't it?

> We're also considering allowing negative ratings

Okay, but you can do signed int with bits if you
really want it, there is even some prior art... ;-)

> That's not true.

Not sure what you consider as "untrue".  It is true
that MAILFROM as an identity for reputation can be
only defined as in RFC 4408 + 4408bis.  It does not
imply that SPF is the only way to do something with
this identity, it means there is no other plausible
way to define what a MAILFROM identity actually is.

> You might develop reputation based on SMTP MAIL
> FROM without checking SPF.  (Might be a dumb idea,
> but you could do it.)

Sure, you could also apply SenderID on Message-IDs.

But you would not suggest a "PRA identity", unless
it is what RFC 4407 says.  Likewise a MAILFROM id.
is what 4408(bis) says.  There is no such thing as
a different "SPF identity"; just remove the latter
from your vocabulary draft.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Oct 2011 02:44:28 -0700

> Sent: Wednesday, October 26, 2011 2:24 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [domainrep] I-D.*-reputation-*.01 (was: A document about reputation data meta-issues)
> 

That would be the DNSBL RFC evaluation record.

> only defined as in RFC 4408 + 4408bis.

RFC821 defined MAIL FROM.  Why can that definition not be used to develop reputation if someone wanted to do that?

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 26 Oct 2011 06:21:34 -0400

> For this purpose UDP is cheaper than TCP, isn't it?

Even if the IESG hadn't made remarks about this, I think you'd find a
certain part of the community screaming in pain if people tried to
recycle the DNSBL mechanism for a new service.  

This is not to say "don't use DNS" (I'm sure there will be such
people, though), but it is to say "don't overload A records".

A

-- 
Andrew Sullivan
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Oct 2011 12:34:11 +0200

On 26 October 2011 11:44, Murray S. Kucherawy wrote:

>> Pointer, please.
[...]
> That would be the DNSBL RFC evaluation record.

<URL:https://datatracker.ietf.org/doc/draft-irtf-asrg-dnsbl/history/>,
apparently.

There's a bunch of [DISCUSS] saying that this should
be PS and DNSOPS instead of "research", because it's
no research.  I don't see that the IETF in 2008 did
not like this peculiar 127.0.0.2/8 usage.

> RFC821 defined MAIL FROM.

I'm talking about the "MAILFROM identity" in your
draft.  Of course that is based on SMTP MAIL FROM,
821/2821/5321/5321bis.  But as an "identity" for
reputation it is defined in 4408/4408bis.

The SMTP RFCs are not about identities, they don't
tell you what to do with an "empty" MAIL FROM if
you want to attach some kind of reputation to it.
RFC 4408 explains this trick.

If some scheme has no use for empty MAIL FROMs it
is fine; otherwise it should follow the definition
in RFC 4408.  Or use another name, "MAILFROM" and
"PRA" are already taken.

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Oct 2011 04:20:50 -0700

> Sent: Wednesday, October 26, 2011 3:34 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

I still don't understand what distinction you're making.  It sounds like you want SPF to get credit for being the first to present the idea of evaluating what MAIL FROM says in a filtering sense.  I think there's plenty of prior art predating SPF in that regard.

If that's not it, I'm lost.

---

From: Dave CROCKER <[email-masked]>
Date: Wed, 26 Oct 2011 13:30:02 +0200

Just to comment on history...

> recycle the DNSBL mechanism for a new service.

That part of the community is indeed quite vigorous about this point.

But the process entirely ignored how thoroughly ingrained this method of 
overloading the use of A records is in the critical function of global email 
reputation list publication and use.

In other words, the methodology has massive rough consensus IN ITS FAVOR, 
demonstrated by very widespread adoption and use.

However, the fact that this violates a purists' sense of what should be 
permitted was the basis for rejecting a previous standardization effort.

If one tried to compare the size of the rough consensus in one direction versus 
another, I believe the scale of actual use dwarfs the scale of the purist 
constituency.  That fact appeared to be irrelevant to the IESG, last time, and I 
wouldn't expect this to have changed.

(But I also don't happen to expect the A-record approach to be relevant to the 
current work...)

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 26 Oct 2011 14:30:12 +0200

On 26 October 2011 13:20, Murray S. Kucherawy wrote:

> I still don't understand what distinction you're
> making.  It sounds like you want SPF to get credit
> for being the first to present the idea of
> evaluating what MAIL FROM says in a filtering sense.

No.  I suggested to delete "SPF" in your vocabulary,
and to use 4408bis as a reference for your "MAIL FROM"
identity.  Quick reality check:

There are 29 occurrences of '"MAIL FROM" identity' in
4408bis (not counting "MAIL FROM" without 'identity').

There is no "SPF identity" in 4408bis.  As you said
there is no other scheme using any other kind of a
"MAIL FROM identity", therefore you don't need to
reserve this term for something that doesn't exist,
just use it "as is".

If folks later invent something else they can pick a
new name, e.g., "SMTP identity" or "envelope identity"
or whatever remotely makes sense from their POV.  But
they should not create any unnecessary confusion with
the '"MAIL FROM" identity' in 4408bis.

> If that's not it, I'm lost.

How d'you feel if I'd use the term "ARF" for some kind
of abuse report format unrelated to RFC 5965?

-Frank

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Oct 2011 05:45:05 -0700

> Sent: Wednesday, October 26, 2011 5:30 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

Assuming you're talking about Section 4.2 of draft-kucherawy-reputation-vocab-identity, maybe I can explain by illustration why that's there.

Suppose I ask about example.com for a reputation.  If the reply comes back with a value, now you know what the reputation provider thinks about that domain.  But that value doesn't tell you much if you don't know how it was computed.  I wouldn't want to use that value in a system that expresses reputation based on DKIM-validated domains if that service is actually collecting data about domains that SPF validated, or indeed domains that weren't validated at all.  So the point of the IDENTITY: part of the reply is to give the client some context, making the reply more meaningful.

So if I give you a reputation of X with "IDENTITY: SPF", I'm saying that's the reputation of X when you're talking about the domain that SPF validated.  If I give you a reputation of X with "IDENTITY: RFC5321.MAILFROM", then I'm talking about that domain when used in the envelope regardless of what SPF said about it.

In that sense, the distinction is necessary.

> reserve this term for something that doesn't exist,

There are such schemes, actually, but they tend to be coupled with other things.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Oct 2011 09:43:30 -0400

On 10/26/2011 08:45 AM, Murray S. Kucherawy wrote:
> So if I give you a reputation of X with "IDENTITY: SPF", I'm saying
> that's the reputation of X when you're talking about the domain that
> SPF validated.  If I give you a reputation of X with "IDENTITY:
> RFC5321.MAILFROM", then I'm talking about that domain when used in
> the envelope regardless of what SPF said about it.
>

It would be interesting to do an evaluation of if it really is 
necessary.  At some level (and I know I'm generalizing here) both DKIM 
validation and SPF pass results output a domain that the domain owner 
have given some level of authorization to.

I don't think it's at all clear that this distinction makes enough 
difference to be worth the complexity associated with maintaining 
multiple types of identity.

Because they have different failure mechanisms, the reverse is not 
necessarily true, but for messages that successfully validate/pass, I'm 
not at all convinced we should care through what mechanism they were 
validated.

For just SPF/DKIM, it probably scales, but if you look beyond that, 
particularly outside the email world, there are a lot of possibilities. 
  If we can fold IDENTITY: $METHOD down to just IDENTITY (where $METHOD 
is whatever is good enough so we don't need to distinguish) then a lot 
of complexity can be avoided.

Scott K

---

From: "John Levine" <[email-masked]>
Date: 27 Oct 2011 12:19:37 -0000

>That would be the DNSBL RFC evaluation record.

RFC 5782 was originally an IRTF draft.  People noted that it was more
appropriate for standards track, so I changed it to that.
Unfortunately, the IESG has trouble dealing with anything related to
spam, and it quickly became clear that it would never get approved, at
least not in a usable form.  So I flipped it back to the IRTF stream
and ran it through that way.

So I wouldn't pay much attention to whatever the evaluation record
says.  I suspect we'll find that we want to return more than 32 bits
of results from a DNS query, so we'll use something other than an A
record, but it's severely premature optimization to worry about that
now.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 27 Oct 2011 08:41:47 -0400

On Wed, Oct 26, 2011 at 01:30:02PM +0200, Dave CROCKER wrote:

> But the process entirely ignored how thoroughly ingrained this
> method of overloading the use of A records is in the critical
> function of global email reputation list publication and use.
> 
> In other words, the methodology has massive rough consensus IN ITS
> FAVOR, demonstrated by very widespread adoption and use.

Pesticide runnoff in streams also has massive rough consensus in its
favour, given the frequency with which we observe people doing that.
Pollution is never a problem for the polluters, or they wouldn't do
it.

> However, the fact that this violates a purists' sense of what should

What's fun about ever mentioning anything to do with this topic in
your presence, Dave, is the way you always stick completely to the
point at hand and try very hard to stick to neutral language.

Whatever the situation in the past, my point was not about whether A
records ought to have been overloaded in the past; my point was that
we have _new_ mechanisms and a _new_ sets of protocols in this case,
and that therefore we should not repeat the approach used in the past,
because some of us believe that approach has negative consequences for
a protocol we have to maintain.  I recognize that it's not a problem
for the email reputation publishers, any more than the death of whole
rivers of fish is a problem for the pesticide users.  I still think
it's a problem.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Oct 2011 18:26:24 -0700

> rivers of fish is a problem for the pesticide users.  I still think
Agreed.

Use of purported "Authorizations" in conjunction with reputation needs 
to consider the resources consumed in macro expansion of message 
elements and unlimited signature transactions processed by recipients.  
All of this in conjunction with efforts aimed at allowing a level of 
abuse that unvaryingly forgives the largest domains and is unable to 
protect other domain reputation's from being poisoned.

IP address authorization is potentially damaging for DNS by expecting 
this protocol to resolve all IPv4 and IPv6 hosts for globally recognized 
domains in a manner that may not be cachable.  In addition to this 
burden with its potential for network amplification, DKIM also expects 
recipients to process an indeterminate number of invalid and valid 
signatures from otherwise unknown sources.

IP address authorization is also potentially damaging for SMTP when used 
in conjunction with shared resources without conventions protecting 
these authorizations.  How can a sender protect themselves or assure 
delivery when their recipients view them through a LSNs?  Does this mean 
RFC6333, RFC5969, LSNs, or shared MTAs can not be used to exchange email?

DKIM is equally bad in this regard, as it offers no validation of a 
domain being accountable for reported abuse.  DKIM only confirms some 
message content had been seen by a domain, but allows abuse by unknown 
actors and therefore permits accountability to be refuted.

This WG has the cart before the horse.  Reputation MUST use scalable 
protocols that base reputation ONLY on AUTHENTICATED identities.

Being able to authenticate MTAs largely supplants a need to rate unknown 
domains or known domains guilty of prior abuse.  SMTP could utilize a 
Kerberos protocol as an introduction method, perhaps offered by 
trustworthy third parties.  By adding authentication, SMTP itself is 
likely to experience a substantial reduction where only tickets are 
processed without increased loads on SMTP, DNS, or other protocols.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 28 Oct 2011 05:13:43 +0200

Andrew,

> Pollution is never a problem for the polluters, or they wouldn't do

Please provide empirical data that the widespread and essential practice of IP 
Address black lists, using A records, has a systems effect equivalent to the 
environmental impact of pesticide runoff.

For that matter, please show /any/ negative consequences other than offense to 
the sensibilities of purists.

Invoking inflammatory parallels imposes an obligation to justify the flames.

> point at hand and try very hard to stick to neutral language.

Thanks for noting that point.  Most people would miss the truth of it, here, and 
think that you were instead intending the comment as an ad hominem dismissive, 
of the type usually considered inappropriate on IETF mailing lists.

Of course, the label 'purists' is unpleasant and does carry some risk of 
eliciting overreaction from folks claiming to have substantive concerns.

Would that they demonstrated the substance.

> we have _new_ mechanisms and a _new_ sets of protocols in this case,

Indeed we do, which was why your citing a concern about A records was so 
puzzling, since I missed the part of the new work that proposes using A records.

Such a proposal would, after all, be the only reason for referencing this 
controversial issue (as long as we are citing the challenge of staying on 
topic...)

Otherwise it would be a case of admonishing folks not to do something that they 
aren't doing and have given no indication of intending to do, and where's the 
constructive point in doing /that/?

d/
-- 

   Dave Crocker

---

From: SM <[email-masked]>
Date: Thu, 27 Oct 2011 20:18:30 -0700

Hi Andrew,
>recycle the DNSBL mechanism for a new service.

Repurposing a DNS A RR is going to be controversial.  BTW, 
overloading DNS TXT RRs can lead to "incorrect" answers.

Regards,
-sm

---

From: Nathaniel Borenstein <[email-masked]>
Date: Sun, 30 Oct 2011 14:59:17 -0500

On Oct 27, 2011, at 8:26 PM, Douglas Otis wrote:

> This WG has the cart before the horse.  Reputation MUST use scalable protocols that base reputation ONLY on AUTHENTICATED identities.

I have to disagree, because in principle I don't believe there is such a thing as an authenticated identity.  There are only identities for which certain kinds of more or less compelling evidence of proof (authentication) has been provided.   With enough supercomputers, I can break many kinds of cryptographic authentication, while for other purposes very weak authentication suffices.  Is an SPF-verified identity authenticated?  DKIM?  PGP?  What if I write an AI program that identifies your writing style with the reliability of a voiceprint?

By analogy, DNA is stronger evidence than fingerprints, which are stronger evidence than eyewitness identification, and yet we often trust the latter anyway.

What matters is knowing what kind of authentication, if any, is available regarding an identity.  If people then differ  in which authentication techniques they trust more or less, that's not our problem.  -- nsb

---

From: "John Levine" <[email-masked]>
Date: 31 Oct 2011 01:29:29 -0000

>base reputation ONLY on AUTHENTICATED identities.

> I have to disagree, because in principle I don't believe there is
>such a thing as an authenticated identity.

We may have a terminology difference here.  In this context, an
authenticated identity is one that's been validated by an external
authority, e.g., a domain in a DKIM signature that has a matching key
in the DNS, as opposed to a domain in an address on the From: line of
a message.  We can have a separate argument about how much to worry
about various ways a bad guy might sneak unusually false information
into the DNS or wherever the validation info lives.

R's,
John

---

From: Nathaniel Borenstein <[email-masked]>
Date: Mon, 31 Oct 2011 10:14:33 -0500

I can live with this if the definition of "external authority" is pretty broad.  If, for example, the lower level network software tells me that a packet comes from a given IP address, I'd contend that an external authority (sort of the aggregate of the transport-layer stack) has "authenticated" a network address.  And if there's a guy with a Ouija board telling me that a message really came from user X, I'd say it has been authenticated by a guy with a Ouija board.  That doesn't mean I necessarily believe either of them, but it means I have a basis for comparing multiple pieces of data of similarly authenticated provenance.

If DKIM authentication says a message came from x@y, but a dozen eyewitnesses saw it typed by a@b as part of a demonstration of how he contends he can fool DKIM, I'd contend that both contentions are authenticated in different ways, and that we have to decide which type of authentication we trust more.  -- Nathaniel

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 31 Oct 2011 11:16:15 -0400

I've modified the order of Dave's original mail, because only part of
it is directly relevant to the list.

On Fri, Oct 28, 2011 at 05:13:43AM +0200, Dave CROCKER wrote:

> Indeed we do, which was why your citing a concern about A records
> was so puzzling, since I missed the part of the new work that
> proposes using A records.
> 
> Such a proposal would, after all, be the only reason for referencing
> this controversial issue (as long as we are citing the challenge of
> staying on topic...)
> 

You posted in the very thread where Frank Ellerman appeared to be
arguing in favour of recycling this mechanism.  And indeed, Murray's
response to that was what I was trying to emphasise.  The thread
starts here:
<http://www.ietf.org/mail-archive/web/domainrep/current/msg00520.html>.
All I was trying to say is that, regardless of what the IESG had said,
there are good DNS protocol reasons not to use a similar mechanism for
new work.  That's why my message said, ". . .if people tried to
recycle the DNSBL mechanism for a new service."
(<http://www.ietf.org/mail-archive/web/domainrep/current/msg00530.html>)
It seems to me that "recycle" and "new service" are clear enough, but
if not perhaps you could suggest different ways of making that point
in future so that I don't end up in a similar rathole with you the
next time around.  I am also prepared to believe that I misread Frank
Ellerman's argument, although I don't see how.  If so, perhaps you
could explain that to me instead of calling me names.

On the wider point (those of you who don't care can tune out now):

> Please provide empirical data that the widespread and essential
> practice of IP Address black lists, using A records, has a systems
> effect equivalent to the environmental impact of pesticide runoff.
> 
> For that matter, please show /any/ negative consequences other than
> offense to the sensibilities of purists.

If you don't like the comparison to pesticide runoff, perhaps air
pollution from cars will be more to your liking.  Whatever analogy
floats your boat, these blacklists are _still_ pollution of the DNS.

First, the negative consequence is obvious: we know that there have
been abandoned BLs where the domains controlling them have been
abandoned.  Afterwards, someone else picks them up and installs an
A-record wildcard for queries to the domain referring not to some
record in the 127.0.0.0 network, but to an active IP address on the
network.  The harm comes from the continued lookup of those records,
with the concomitant (worthless) load for the rest of the DNS.  That
this would happen was a straightforward consequence of overloading a
datatype that already had a well-defined meaning in the DNS.

Second, because of the widespread deployment of DNS-based lists of
this sort, protocol maintainers, protocol operators, and for that
matter, address space maintainers (since the BL trick uses 127.0.0.0/8
network, providing one more way in which those unassigned addresses
can't be repurposed in future) have to take into account these
deployments when making future decisions.

More importantly, however, you have the burden of proof wrong here.
The DNS is a typed database.  The A record is a type that is supposed
to be used to provide IPv4 addresses.  BLs overload the type to mean,
instead, "IPv4 addresses or else some metainformation according to the
conventions of the data provider", which is a rather gross change to
the type system of the DNS, especially since there is no in-protocol
way of signalling which of these two mutually-exclusive meanings the A
record has.  It is not the responsibility of the protocol maintainers
to show that someone changing the semantics of protocol elements are
doing positive harm; it is instead the responsibility of the would-be
semantics-changers to show that what they are doing does not cause
harm.  As nearly as I can tell, the BL argument always relied on the
implicit assumption, "And the data won't leak."  Given the evidence we
have that any such assumption on the Internet is wrong, I think the
argument in favour of the overloading of DNS data types to do all this
falls down.  Each car on the road, or each application of pesticide,
does not by itself do harm to the natural environment.  It is still
the responsibility of the would-be users to show that they're not
going to do such harm -- because as a matter of fact the widespread
use of these pollutants has caused problems, even though no particular
instance itself does such harm and even though the harms were perhaps
not obvious when the substances started being deployed.

But all of that history is irrelevant for the point I was originally
making; see the beginning of this message.

> Thanks for noting that point.  Most people would miss the truth of
> it, here, and think that you were instead intending the comment as
> an ad hominem dismissive, of the type usually considered
> inappropriate on IETF mailing lists.

If you're going to waive around _ad hominem_ abusives, calling people
"purists", Dave, then you might expect responses in kind.  But I'll
say instead that pointing out that someone is calling people names
instead of sticking to the point (and perhaps, noting that it is not
the first time) is not an _ad hominem_.  It's calling a relevance
fallacy what it is: fallacious.  There are in fact problems with
overloading DNS data types in the way you seem to like to do.  In my
experience, when I point those out to you, you simply deny that there
is a problem, and call me a purist.  This is easy for you, because
you're not the stuckee when the protocol you're supposed to be
maintaining grows all sorts of hairs and warts because of this
behaviour on someone else's part.  I'd have thought, however, that the
difficulty of producing anything like a comprehensible underscore
registry, due to the many fun ways that mechanism has been used, would
have illustrated to you the very point I'm making.

I do not deny that the A-record hack for BLs, and the underscore hacks
we have also seen, are sometimes useful; I use them myself sometimes.
I also recognize, as you appear not to acknowledge, that it is in
practice more difficult than we would like to deploy a new RRTYPE.
But none of that changes the fundamental fact that the DNS tricks we
are talking about are not terribly clean hacks.  They mostly work in
practice, but they break the protocol assumptions, thereby making the
protocol more fragile.  I would have liked to believe that, at the
IETF, we already agreed that breaking a protocol's assumptions on
purpose was at least not obviously ok, even if we do it sometimes.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 31 Oct 2011 17:26:19 +0100

On 31 October 2011 16:16, Andrew Sullivan wrote:

> there are good DNS protocol reasons not to use a
> similar mechanism for new work.

IMHO the known issues with the 127.0.0.2/8 hack are
addressed in the two ASRG RFCs.  And it's perfectly
fine if REPUTE uses other and/or better mechanisms
for its purposes.

I didn't look into I-D.irtf-asrg-iar-howe-siq-03
for some years, it didn't suggest DNSBLs.  (@Murray:
If you didn't know it check it out, there are some
similarities with your I-Ds).

> I am also prepared to believe that I misread Frank
> Ellerman's argument

No, but we can dismiss it as irrelevant for the work
here, because 2*8+7 bits are apparently never enough for REPUTE, and
besides it's not the time to discuss
"encoding optimizations", as noted by Dave and John.

> there have been abandoned BLs where the domains
> controlling them have been abandoned.

Yes, on the client side that's addressed by two test
queries, one test resulting in a conventional LISTED
reply, and another test never resulting in LISTED.

If clients use these tests they can detect most silly
states (DNSBL down or DNSBL listing the world), and
stop to waste bandwidth for pointless DNS queries.

Some of the recommendations for DNSBL providers might
be also interesting for whatever REPUTE will suggest:

"Listing the world" only to get rid of clients still
trying to use a long dead service is not funny, no
matter how these queries are implemented (DNSBL, SIQ,
WHOIS UDP/TCP, HTTP, whatever).

-Frank

---

From: "John R. Levine" <[email-masked]>
Date: 31 Oct 2011 12:32:26 -0400

On Mon, 31 Oct 2011, Nathaniel Borenstein wrote:

> I can live with this if the definition of "external authority" is
>pretty broad.  If, for example, the lower level network software
>tells me that a packet comes from a given IP address, I'd contend
>that an external authority (sort of the aggregate of the
>transport-layer stack) has "authenticated" a network address. ...

I think we generally agree, although I'd consider an IP address from
a TCP session more authenticated than one from a single UDP packet. 
There's a swamp of how credible an authenticator is, but I think we can 
get by with an arbitrary division between authenticated meaning hard to 
fake, and unauthenticated meaning easy to fake.

> If DKIM authentication says a message came from x@y, ...

Please report immediately for self-criticism and re-education.  DKIM
doesn't do that.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 31 Oct 2011 13:20:27 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nathaniel Borenstein
> Sent: Monday, October 31, 2011 8:15 AM
> To: John Levine
> Cc: [email-masked]
> pretty broad.  If, for example, the lower level network software tells
> me that a packet comes from a given IP address, I'd contend that an
> external authority (sort of the aggregate of the transport-layer stack)
> has "authenticated" a network address.  And if there's a guy with a
> Ouija board telling me that a message really came from user X, I'd say
> it has been authenticated by a guy with a Ouija board.  That doesn't
> mean I necessarily believe either of them, but it means I have a basis
> for comparing multiple pieces of data of similarly authenticated
> provenance.
> [...]

This is why I put the "IDENTITY:" mechanism into the media type.  It allows the server to make clear to the client that "reputation for X is Y, provided you confirmed X through mechanism Z, because that's how I came to this conclusion".  It allows the client to confirm that apples are being compared to apples.

In my view, deciding which methods to trust, for both parties, is a matter for those parties to decide on their own and not a topic for REPUTE to reopen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Oct 2011 15:33:47 -0700

On 10/30/11 6:29 PM, John Levine wrote:
>  authority, e.g., a domain in a DKIM signature that has a matching
>  key in the DNS, as opposed to a domain in an address on the From:
>  line of a message.

While DKIM authenticates a domain has signed a portion of a message, it 
does not authenticate whether this domain transmitted the message to a 
particular recipient.  DKIM signatures do not capture SMTP elements 
necessary to assign accountability for the transmission of unwanted and 
abusive messages.  By design DKIM does NOT restrict who sent a valid 
message or to whom.

Spammers often lie and have even been known to threaten litigation.  
Anyone can assert a negative reputation placed against their domain is 
in error and is causing them harm.  Resisting demands that negative 
reputations be changed must be backed by information able to withstand 
scrutiny.

Clever spammers can easily ensure valid DKIM signatures leave the actual 
transmitter in doubt.  The entity held accountable through reputation 
assignment for the sending of spam MUST be the entity AUTHENTICATED.  
SMTP accountability should begin by authenticating the administrative 
domain of the outbound MTA.  In order to safely accomplish the necessary 
authentications, SMTP Auth, DANE, and Kerberos tickets could be used to 
establish a basis upon which reputations can be fairly and equitably 
established.

While DKIM may play a role in mitigating phishing attacks, DKIM lacks 
SMTP specific information necessary to safely hold the transmitters of 
messages accountable.  The transmitters of a message are not 
authenticated by DKIM, nor are they with SPF.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 31 Oct 2011 18:28:27 -0700

> In my view, deciding which methods to trust, for both parties, is a matter for those parties to decide on their own and not a topic for REPUTE to reopen.

+1

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

---

From: Chris Lewis <[email-masked]>
Date: Mon, 31 Oct 2011 22:39:53 -0400

> WHOIS UDP/TCP, HTTP, whatever).

While the wildcarded domain returning a non 127/8 address is a risk, it 
seems to be mostly a theoretical one.  It's happened before, and the 
consequences have been unnoticable on the whole.  It seems more frequent 
that individual sites screw up their DNSBL query config to the extent 
that it always returns what they think is a listing.  Eg: misspelling 
the query zone, or miss-parsing received lines.

It seems that most of the clients now insist on 127/8 addresses, if not 
exact values, and most aren't affected.  The "market" has improved in 
quality over the years.

All of the list-the-world instances we've heard about have been 
_deliberate_, either by the original DNSBL operator, or by the new owner 
of the domain, where they've arranged it to return the specific 
127.x.x.x address that indicates listing.

As such, no matter how we defined a reputation service, this same risk 
of "list the world" remains, and for much the same reasons.   We could 
authenticate the results somehow, but that still won't prevent a 
reputation provider deliberately going rogue.

I don't think we can solve that problem in a protocol specification.