Subject: Re: Consent (was Re: [Asrg] seeking comments on new RMX article )

From: J C Lawrence <[email-masked]>
Date: Wed, 07 May 2003 14:19:28 -0700

On Wed, 7 May 2003 13:14:59 -0700
Phillip Hallam-Baker <Hallam-Baker> wrote:

>> Should the holder of the DNS keys be a dictator over all the mail
>> sent from his domain?  You say, "Yes!"  I say, "Hell no!"

> Domain names are not a scarce resource.

They are not scarce technically.  They can be scarce politically.

> The only way that you can in the long term protect your identity in
> cyberspace is to control your own domain.

I don't want to argue this point.  I largely came to that view as a
pragmatic statement several years back (and thus registered kanga.nu,
not being willing to deal with NSI), but haven't worked thru it well
enough to state an absolute.

> The domain name owner can decide what mail you receive. I see no
> reason why control over what is sent is an ideological issue.

The DNS master can control whether or not I receive mail at all under
that domain, and can only do so in an externally obvious fashion.  He
can't control what mail I receive, just whether or not I receive any
mail (well, he could do mail forwards, but that's explicitly obvious
from an external view).

Use of RMX, like an inbound MX, gives the DNSmaster and operators of the
smarthost review and editorial capacity over every message sent.  It is
no longer possible to either send or receive an individual message (not
mail in general, but any specific message) without the blessing of the
DNS gods.

> I much prefer the concept that everyone is master of their own domain
> than we have to submit to the predjudices of whoever the self
> appointed censor of the week would be.

Agreed, tho there are non-trivial human scaling and service industry
costs there.

--
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
[email-masked]               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Michael Rubel <[email-masked]>
Date: Wed, 7 May 2003 16:08:13 -0700 (PDT)

JCL> Use of RMX, like an inbound MX, gives the DNSmaster and operators of
JCL> the smarthost review and editorial capacity over every message sent.
JCL> It is no longer possible to either send or receive an individual
JCL> message (not mail in general, but any specific message) without the
JCL> blessing of the DNS gods.

J.C.,

Can this really be how you feel?  That a domain owner should not have
the ability to decide what mail gets sent in his or her own name?  I
don't agree.  I didn't appreciate seeing thousands of raunchy
unsolicited advertisements go out over the Internet, signed "webmaster
(at) mikerubel.org."  I feel that whoever sent them had no right to use
my name.  But without RMX, there was nothing I could do about it.

I appreciate the censorship argument, but so long as senders are free to
choose from among a wide variety of different hosting domains, with a
wide variety of sending policies--including the option of operating
their own domains and setting their own policies, as many of us have
done--I won't buy the argument that giving domain owners control over
their domains will somehow lead to 1984 incarnate.  The freedom of a
sender to send whatever he wants need not extend to libel of third 
parties.

Mike

---

From: J C Lawrence <[email-masked]>
Date: Wed, 07 May 2003 17:03:36 -0700

On Wed, 7 May 2003 16:08:13 -0700 (PDT) 
Michael Rubel <[email-masked]> wrote:

>> Use of RMX, like an inbound MX, gives the DNSmaster and operators
>> of the smarthost review and editorial capacity over every message
>> sent.  It is no longer possible to either send or receive an
>> individual message (not mail in general, but any specific message)
>> without the blessing of the DNS gods.

> Can this really be how you feel?  

Yes.

> That a domain owner should not have the ability to decide what mail
> gets sent in his or her own name?  

Yes.

> I don't agree.  I didn't appreciate seeing thousands of raunchy
> (at) mikerubel.org."  I feel that whoever sent them had no right to
> use my name.  

I feel quite similarly.

> But without RMX, there was nothing I could do about it.

Here we part.  I don't consider RMX to be a suitable address to the
problem.

> The freedom of a sender to send whatever he wants need not extend to
> libel of third parties.

Absolutely.  Therefore the problem is to find another more welcome and
facile solution.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 7 May 2003 13:14:59 -0700

> Should the holder of the DNS keys be a dictator over all the mail sent
> from his domain?  You say, "Yes!"  I say, "Hell no!"  

Domain names are not a scarce resource. The only way that you can in the
long term protect your identity in cyberspace is to control your own domain.

The domain name owner can decide what mail you receive. I see no reason why
control over what is sent is an ideological issue.

I much prefer the concept that everyone is master of their own domain than
we have to submit to the predjudices of whoever the self appointed censor of
the week would be. 

		Phill

---

From: Michael Rubel <[email-masked]>
Date: Wed, 7 May 2003 23:04:02 -0700 (PDT)

J.C.,

MR> But without RMX, there was nothing I could do about it.

JCL> Here we part.  I don't consider RMX to be a suitable address to the
JCL> problem.

Just to be clear, I'm assuming you mean by this that you agree RMX would
fix the forgery problem at a technical level, but are not satisfied with
RMX because it gives domain administrators per-message control over their
outgoing mail, rather than per-sender control.  Is that correct?

If this is your opinion, I respect it, but I disagree; I don't feel that
making it technologically impossible for a domain to apply message-level
controls to its outgoing mail is a desirable feature.  This is because if
we are to feel justified in holding domain admins responsible for spam
from their domains, then we owe them the reasonable opportunity to prevent
it.

Nevertheless, even if I disagree with your opinion, I concede that it
deserves to be heard.  If you send me a paragraph or two explaining why
you feel that message-level controls ought to be impossible, I will add it
to the RMX page so that others are made aware of the issue.  Furthermore,
if you can think of a reasonable alternative and provide a link, I'll
include it.

Regards,
Mike

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 08:42:52 +0200

> > gets sent in his or her own name?  

I think that's the point where every further discussion becomes
futile.

Hadmut

---

From: J C Lawrence <[email-masked]>
Date: Thu, 08 May 2003 00:05:21 -0700

On Wed, 7 May 2003 23:04:02 -0700 (PDT) 

> Just to be clear, I'm assuming you mean by this that you agree RMX
> would fix the forgery problem at a technical level, but are not
> satisfied with RMX because it gives domain administrators per-message
> control over their outgoing mail, rather than per-sender control.  Is
> that correct?

Almost.  RMX would not fix or prevent the forgery problem, but it would
curtail some of the more obvious abuses, but achieves that end by a
large reduction in the capabilities and freedoms of the current
arrangement.  Its a bandaide, not a fix (bandaides are Okay, but should
be recognised as such).

My gripes with RMX are various and not limited to the recent authority
domain discussion; ranging from deployment costs to percentage
deployment threshold requirements, social implications, breaking of
extant useful architectures, and a relatively poor value in the level of
authentication it provides (due to the reliance on side-effects of the
record).

> If this is your opinion, I respect it, but I disagree; I don't feel
> that making it technologically impossible for a domain to apply
> message-level controls to its outgoing mail is a desirable feature.
> This is because if we are to feel justified in holding domain admins
> responsible for spam from their domains, then we owe them the
> reasonable opportunity to prevent it.

Oh come now!  We don't hold domain operators responsible for spam
claiming to be from their domain, and never have.  That's a ridiculous
red herring.  We hold network and host operators responsible for spam.
The problem has never been identifying domain operators, but correctly
identifying networks and hosts and then the people behind them.  The
actually fundamental value that RMX adds in this space is based on the
fact that it requires outbound mail to be routed thru domain-named IP
addresses, and ONLY routed thru those addresses so that they can be used
in an effort to provide a better back trail to the network and host
operators responsible for originating the spam.  Without that
centralised routing RMX sunders.  The use of the domain is just a
foreign key in the identification transaction, nothing else -- its a key
that you use to map a received mail back to an IP address which you can
lookup in WHOIS and hit or react appropriately with at least some minor
semblance of correctness.

RMX is a targeting tool, and one with rather poor guarantees and audit
trails.  Its a particularly ugly targeting protocol as the natural
inclination on the receiving end is to ignore the identified targets and
to instead simply ghetto-ise those without targeting identifiers, while
the sending end is naturally tempted to machine wash all mail sent.

> If you send me a paragraph or two explaining why you feel that
> message-level controls ought to be impossible...

Arrrgh.  That is not and has never been my contention.  

Here's the condensed version:

  The sending and receipt of a mail is a contract between the sender and
  the recipient.  The definition and terms of that contract are
  subjective to those involved.  The use of external symbols and
  referents in the contract, like domain names, is relevant to those
  involved in the contract, not the referents.

Mail, like all human communication, is an autonomous peer-to-peer thing.
Domain names and the rest of that are convenience trappings and
abstractions, no more.

> Furthermore, if you can think of a reasonable alternative and provide
> a link, I'll include it.

<nod> I'm working on it.  Its a rough space -- you've got three nodes
among DNS, the originating node, and emitted message, and establishing
validation creds for a message (not an SMTP transaction) without
requiring a shared secret between DNS and the emitting node is rough.

---

From: J C Lawrence <[email-masked]>
Date: Thu, 08 May 2003 00:07:21 -0700

On Thu, 8 May 2003 08:42:52 +0200 

> I think that's the point where every further discussion becomes

Domain names are convenience tokens, addressing shorthands, not first
class tokens or identities.

---

From: Hadmut Danisch <[email-masked]>
Date: Thu, 8 May 2003 09:14:46 +0200

> class tokens or identities.

What exactly makes you believe that? Any quotes? Or is this your
personal opinion?

Hadmut

---

From: J C Lawrence <[email-masked]>
Date: Thu, 08 May 2003 10:01:17 -0700

On Thu, 8 May 2003 09:14:46 +0200 

> What exactly makes you believe that? 

That is their function.  Domain names are human friendly strings which
can be used as keys in DNS lookups to derive IP information, they are
provided again as keys in virtual hosting protocols as a key to the
delivery target.  They're functionally a shorthand notation for, "That
IP" and "that delivery service at that IP" -- they have no direct
representation or use other than as lookup keys.

> Any quotes? 

I don't hold or spread views based on their popularity -- no fact was
changed by the number of people that believed it.

> Or is this your personal opinion?

Would I say something that wasn't?

---

From: Markus Stumpf <[email-masked]>
Date: Fri, 9 May 2003 00:26:57 +0200

> representation or use other than as lookup keys.

you also wrote:
*> Domain names are convenience tokens, addressing shorthands, not first
*> class tokens or identities.

These two paragraphs are contrary.
In the environment of name based virtual hosts "that IP" will give you
nothing associated with "domain name" without providing it, so it is a
primary key.
Same for email. smtp.easydns.com is MX for kanga.nu. Injecting a email
addressed to "claw" at  smtp.easydns.com  will not make it to kanga.nu
without providing the domain name. So this is a primary key.
    220 smtp.easydns.com ESMTP spoken here.
    MAIL FROM: <[email-masked]>
    250 Ok
    RCPT TO: <claw>
    554 <claw>: Recipient address rejected: Relay access denied

I'm both examples it is not the sole primary key, but you need both
to accomplish the task.

	\Maex

-- 
SpaceNet AG            | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development |       D-80807 Muenchen    | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
 proportional to the amount of vacuity between the ears of the admin"
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Mike Rubel <[email-masked]>
Date: Fri, 9 May 2003 00:54:14 -0700 (PDT)

J.C.,

JCL> My gripes with RMX
[ ... (include) ... ]
JCL> ...a relatively poor value in the level of authentication it provides
JCL> (due to the reliance on side-effects of the record).

I disagree, but you aren't giving me something specific to respond to
here.

MR> If this is your opinion, I respect it, but I disagree; I don't feel
MR> that making it technologically impossible for a domain to apply
MR> message-level controls to its outgoing mail is a desirable feature.
MR> This is because if we are to feel justified in holding domain admins
MR> responsible for spam from their domains, then we owe them the
MR> reasonable opportunity to prevent it.

JCL> Oh come now!  We don't hold domain operators responsible for spam
JCL> claiming to be from their domain, and never have.  That's a ridiculous
JCL> red herring.

Not at all.  Domain admins suffer by being blacklisted when their domain
names are misused.  Some recipients dump any mail claiming to originate
from hotmail.com, regardless of its true source, for example.  It is in
this sense that domain owners are held responsible.  For the record I
don't agree with content filtering, but that choice belongs with the
domain owner, not me.

Content filtering is not the only option, either.

By allowing domain owners to impose outbound SMTP rate limiting, RMX
gives them the power to prevent their names from being used to deliver
bulk spam even when their clients' poorly-secured desktop machines are
compromised.

JCL> The actually fundamental value that RMX adds in this space is based on
JCL> the fact that it requires outbound mail to be routed thru domain-named
JCL> IP addresses, and ONLY routed thru those addresses so that they can be
JCL> used in an effort to provide a better back trail to the network and
JCL> host operators responsible for originating the spam.

I'm not interested in chasing down the spammer; I just want to minimize
the probability that his messages successfully reach me, particularly if
they're deliberately misleading.  RMX helps there.

MR> RMX is a targeting tool, and one with rather poor guarantees and audit
MR> trails.

RMX isn't supposed to produce auditing trails, except in the case of
legitimate (non-forged) mail.  I believe its true design features stand on
their own.

> Its a particularly ugly targeting protocol as the natural inclination
> on the receiving end is to ignore the identified targets and to
> instead simply ghetto-ise those without targeting identifiers, while

You have a point about sending domains being tempted to machine-wash
outgoing mail, but this temptation is balanced by privacy concerns of
their customers, who have no shortage of options when it comes to mail
providers.

As far as recipients' temptations go, would you also argue that refusal
to accept mail from open relays is somehow unfair to the operators of
those relays?  If the operators don't like being ignored, they are free
to close the hole, which in this case means implementing RMX.  This is a 
feature which encourages adoption, not a bug.

JCL> Here's the condensed version:
JCL> 
JCL>   The sending and receipt of a mail is a contract between the sender and
JCL>   the recipient.  The definition and terms of that contract are
JCL>   subjective to those involved.  The use of external symbols and
JCL>   referents in the contract, like domain names, is relevant to those
JCL>   involved in the contract, not the referents.
JCL> 
JCL> Mail, like all human communication, is an autonomous peer-to-peer thing.
JCL> Domain names and the rest of that are convenience trappings and
JCL> abstractions, no more.

I disagree; no contract exists, not even an implied one.  In the case of
spam, the recipient specifically does not want it.

RMX enables a check, on behalf of the recipient, with an interested party
(the sending domain) which has both the ability and the responsibility to
certify that the message originated there.  If the message proves to be
spam, the recipient is less likely to accept mail from that domain in the
future.

MR> Furthermore, if you can think of a reasonable alternative and provide
MR> a link, I'll include it.

JCL> <nod> I'm working on it.  Its a rough space -- you've got three nodes
JCL> among DNS, the originating node, and emitted message, and establishing
JCL> validation creds for a message (not an SMTP transaction) without
JCL> requiring a shared secret between DNS and the emitting node is rough.

Keep me posted!

Best regards,
Mike

---

From: "Tom Thomson" <[email-masked]>
Date: Tue, 13 May 2003 16:43:13 +0100

JCL's objection to RMX that it gives the DNS admin too much control strikes
a chord with me. However, I do think that the DNS admin should have some
control over email from his domain: specifically, he should have control
over who sends mail purporting to be from that domain.  Like JCL, I don't
think he should have control over what mail is sent in the way that RMX
would give him it (mostly because RMX would allow him to force all mail
through some particular MTAs where he could do content filtering).

So I guess we need a proposal which gives the DNS admin the right level of
control.

Here is a first rough idea.

The DNS admin provides a set of public keys as new DNS records (along the
lines of Paul Vixie's proposed Mail From MX records, so no big
implementation hassle for DNS) along with a key index for each key (just a
tag distinguishing it from all the other keys for the same domain).  He
hands out corresponding private keys to people who are authorised to send
email apparently from his domain.  He can choose to have only one key for
everyone, to give different keys to different groups or individuals, to give
some people more than one key, and so on.

Note that there's no trusted third party actring as a CA or anything similar
here.  The domain admin creates key pairs, the public keys don't have to be
certified or signed by anyone.

Then we change the HELO command so that it takes the form

HELO SP <hostname> SP K<key index> SP <seed> SP <expiry date> SP <start
date> SP <signature> CR LF
[where <hostname> SP is optional]
(maybe it would be cleaner to use extended SMTP and put this stuff as
parameters on the MAIL FROM line)
where
  <key index> indicates which of the domains key pairs is used for the
signature
  <seed> is some "random" data
  <expiry date> is the last time at which the signature is to be considered
valid
  <start date> is the time at which the signature was formed
  <signature> is the result of encrypting (RSA, using the private key for
the domain corresponding to <key index>) the contents of the helo line
following K and preceding <signature> concatenated with the adress in the
MAIL_FROM line.

A receiving MTA checks the signature.  If it doesn't work, the message is a
forgery.  If it does work, it's genuine or there's been a replay attack.  If
SP K SP doesn't occur on the helo line, the MTA can't do the checks and we
don't know anything.  If the <key index> is out of range, the message is a
forgery.  If the MTA doesn't do the check, we don't know anything.  If the
MTA is a relay, it should pass the part of the helo line from SP K SP to the
end on to the next MTA in its helo line, but current MTAs certainly wont so
MTAs downstream of them can't do any checks.

This doesn't identify individual senders unless the domain has handed out
individual keys.  If the domain owner wants to get RMX like behaviour and
excercise dictatorial control, he gives the keys to no-one and generates the
signatures in his smart-host. If the domain owner doesn't want to play this
game, he doesn't provide any key records in DNS.

The problems I see are
  replays: could be fixed by signing message body (excluding content
headers, since MTAs can add to these) and is mitigated by the timestamps
  not-attributable mail:  we only identify the domain which has permitted
the sender to use its name.
  mail list expanders have to re-sign if they change the envelope mail_from
  users will leak keys all over the place
  requires change to MUA as well as MTA

The advantages:
  Eliminates the "dictatorship" objection to RMX (but allows domains to be
set up as dictatorships if the domain owner wants them that way)
  It doesn't require certificates and CAs
  It doesn't need a key per mail user, and mail users don't get involved in
generating keys

S-MIME and PGP are technically better than this but require per-user keys
and do require certification (an unsigned PGP key on a PGP key-server is
useless for authentication, isn't it, and completely useless for tracing the
source of an email) which are things to avoid if we want any significant
deployment. They aren't any better about leaking keys (if every user has a
key, many of them will leak their keys). So looking at practicality rather
than technical goodness, I think this could be the basis of something
better.

Tom

---

From: "Eric Dean" <[email-masked]>
Date: Tue, 13 May 2003 12:45:43 -0400

> tag distinguishing it from all the other keys for the same domain).

DNS has a rarely used Options field whereby you can insert various
information.  We were going to use it for DNS-based content delivery
interworking (CDI)..though that WG is all but dead.  We had used it to pass
the source IP of the originating resolver so that the destination CDN could
best geo-position the content.  Such a field might come into play here and
is fully interoperable with all DNS servers..it's simply igntored.

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 13:54:49 -0400

>is fully interoperable with all DNS servers..it's simply igntored.

Anytime we want to get involved with DNS, we must keep in mind the current 
state of security of the entire DNS system. If we end up defining some form 
of a DNS-based standard, perhaps we should mandate the use of secure DNS.

Yakov

---------------------------------------------------------------------------------------------------
Yakov Shafranovich / <[email-masked]>
SolidMatrix Research, a division of SolidMatrix Technologies, Inc.
---------------------------------------------------------------------------------------------------
"One who watches the wind will never sow, and one who keeps his eyes on
the clouds will never reap" (Ecclesiastes 11:4)
---------------------------------------------------------------------------------------------------

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 13:54:49 -0400

Yakov

---

From: Michael Rubel <[email-masked]>
Date: Tue, 13 May 2003 11:39:21 -0700 (PDT)

> set up as dictatorships if the domain owner wants them that way)

Hi Tom,

Just to clarify, RMX-like proposals give a sending domain the ability to
act as dictator if its owner wishes, but do not mandate that it act as
dictator.  The domain owner may choose not to filter outgoing content.  
(Indeed, if RMX were available to me, I would definitely not
content-filter outgoing messages from other users at my domain, except in
the context of virus defense--in which case it would be an optional
feature).  This decision would fall under the scope of a privacy policy.

Your crypto-based alternative also allows the domain owner to act as 
dictator if he/she wishes, by withholding the signing key.  There are 
security advantages to going this way, even if there is no intent to 
filter, since it prevents the key leakage.

So would you say that the principal advantage of the crypto approach is
that it prevents the domain from acting as dictator while plausibly
denying same?

If so, do you believe this advantage is worth the additional 
implementation cost?

Please bear in mind that a user may choose any domain on the Internet
willing to offer mail service, and may even operate his/her own domain.
This seems vastly less restrictive than the current situation, wherein the
user would be left with few options if his/her ISP started filtering
outgoing mail (intercept outbound port 25).  The ISP also has an incentive
to do so--to avoid being blacklisted!

Thanks,
Mike

---

From: Vernon Schryver <[email-masked]>
Date: Tue, 13 May 2003 13:35:08 -0600 (MDT)

> From: Yakov Shafranovich <[email-masked]>

> ...

Speaking of the current state of security of the entire DNS system,
have you been watching the years long saga of DNSSEC?  Given the local
rule that deployment considerations matter, are you sure you'd want
to tie any spam defense to DNSSEC?

Vernon Schryver    [email-masked]
_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg

---

From: Yakov Shafranovich <[email-masked]>
Date: Tue, 13 May 2003 16:34:39 -0400

>to tie any spam defense to DNSSEC?

No I am not sure - I am just trying to point out that security is an issue 
with DNS, and anything relying on DNS should take that into consideration.

Yakov

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 14 May 2003 11:08:49 +0100

> of a DNS-based standard, perhaps we should mandate the use of secure DNS.

Unfortunately DNSSEC is pretty big and horrible and all tied together so
that one can't pick parts of it.  It would be nice if DNSSEC were
implemented throughout the net, but I don't think it's going to happen in my
lifetime.  So mandating secure DNS as part of a solution effectively rules
that solution out, unless secure DNS means something quite different from
DNSSEC.

The various partial solutions we apply don't need to be perfect either
individually or even in combination: let's remember "worse is better"
especially when worse is good enough.

Tom

---

From: "Tom Thomson" <[email-masked]>
Date: Wed, 14 May 2003 11:21:36 +0100

> feature).  This decision would fall under the scope of a privacy policy.

One part of the problem is that it determines not who can send mail but
where mail can be sent from. So you could decide not to authorising sending
from domains without outgoing political correctness filters, not to
authorise sending throgh domains that didn't agree to secretly send a copy
to you, and so on.  It's not just a privacy policy but also a freedom of
speech policy that's needed here.

> that it prevents the domain from acting as dictator while plausibly

Well, the idea is to give users the keys, which means there will be leakage
and you have to change them often.  If you don't give users the keys you
force them into your outgoing relays and that's as bad as RMX. So this
proposal doesn't work if you want to be really secure.

> If so, do you believe this advantage is worth the additional

Yes, the advantage of giving people a token rather than saying which
transmitters they can use are worth the hassle.

> to do so--to avoid being blacklisted!

It gets to be quite fun, all sorts of new possibilities turn up.  For
example you could blacklist not the domain but a particular key index of the
domain.  So there's an incentive for the domain owner to have quite a few
keys  and use them to distinguish groups.

Tom