Subject: RE: Why not XML

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 23 Jun 2004 06:37:46 -0700

> We have to be ready to deal with BOTH reactions, and since they are 
> emotional reactions, we can't explain them away.  We can get 
> around them, 
> but not with engineering powers... the power to change an emotional 
> reaction is reserved only for the marketers :)

If the objection to XML is entirely emotional surely our duty is to
choose the right architectutral approach.

The computing world decided that ASCII was its interchange standard
a long time ago.

Over the past five years the computing world decided that XML was
its standard for data structures.

This is a standards body, building standards on standards is usually
considered to be the right approach to take.

		Phill

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 23 Jun 2004 08:57:14 -0500

> considered to be the right approach to take.

...where it makes sense.

Trying to tunnel HTTP/XML data-models over DNS doesn't make anymore sense
than trying to flop it into ARP or ICMP or any other query/response
datagram protocol.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 23 Jun 2004 10:34:36 -0400

> than trying to flop it into ARP or ICMP or any other query/response

  Similarly, trying to put URLs into DNS, and MARID data on web pages
wouldn't make sense, as email would be dependent on yet another set of
services.

  What about putting the MARID data in-line in SMTP via an extension?
It can be signed, and the keys can go into DNS ala DK, which should
validate it.  It does mean that the barrier for adoption is higher, as
more software has to change, but it does avoid the above problems.

  Of course, it means that caching of the data becomes more
problematic.  DNS takes care of that automatically, and that won't be
possible if the data is inline.  But at ~100 bytes per typical MARID
record, itwouldn't be much of a problem to just re-send it.

  Alan DeKok.

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 23 Jun 2004 10:44:00 -0500

> more software has to change, but it does avoid the above problems.

There are lots of good reasons to do this. For one thing, you can define
whatever lookup-keys you want, meaning that you can ~extend into per-user
policy statements, for example. You can also take advantage of existing
AUTH mechanisms to publish ~public policies versus ~private policies. It
seems to me that if we really want infinitely extensible policy docs,
these kinds of features are going to be important, and given that DNS
*DOES NOT* support these kinds of things easily that an appropriate design
would favor some kind of service.

Note that all of the above assumes that policy will be interpreted by the
recipient system, which is not necessarily required. A sender-side policy
daemon that returns YES/NO/MAYBE could also work.

> record, itwouldn't be much of a problem to just re-send it.

Cache meta-data can be embedded into the XML pretty easily (especially if
message-size is no longer an issue), so the real issue is tracking and
cleanup code, which nobody wants to write, and which comes with DNS 'for
free' [sic].

There are other problems with reusing SMTP -- the biggest one I can think
of is the excessive number of round-trip times, which imposes significant
latency considerations. Connect->HELO->POLICY-> to a laden serve behind a
slow link in ~Ukraine can be expensive.

Probably the best generalized approach to the "where's the policy" issue
(assumng such a design is taken) is to use a URI syntax, and to define
things like SMTP:host and SMTP:MX:domain as eligible candidates (those
syntaxes would be useful for other things anyway).

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 18:32:24 +0200

Alan DeKok wrote:

>validate it. 

Actually not a bad idea, but two counter arguments:

- This is based on cryptography. This means it has to cope with
  secret keys. We do not have the hardware to keep secret
  keys secret. Remember that there are spam armys built from
  hundres of thousands of machines infected with mailicous
  code. This code is already collected license keys and such stuff.

  The same people who wrote this software would immediately
  start to write  routines to collect the keys to generate
  false records. Today you can buy collections of e-mail address
  lists. Tomorrow they will come with stolen keys.

  You would need to have a highly protected issuer of such
  records. Do you thing thats practical and feasible?

- If you, on the other hand, give every sender or domain owner
  a key to generate the record himself, why to bother with this
  at all? Why not simply signing the message itself?

regards
Hadmut

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 23 Jun 2004 13:16:39 -0400

> slow link in ~Ukraine can be expensive.

  It's one more SMTP command/response transaction, but that process
can be shortened.  e.g. As a hack, putting a hash of the policy into
the EHLO name.  If the recipient recognizes the hash, then the server
knows the policy, can apply it, and SMTP proceeds unchanged.  If the
server doesn't recognize the hash, it can respond with a "policy"
request, while simultaneously doing a DNS lookup for the key which
signs that policy.

  In that case, the policy exchange imposes a latency once, and then
it can be cached.  All that has to go into DNS is a key for signing
policies, and a statement saying "yes, we have an SMTP policy: please
use SMTP extensions to ask for it."

  If rogue clients claim association with a domain, they either won't
supply a policy (and thus get rejected, due to the domains published
requirements), or they can supply a non-signed policy (and thus get
rejected), or they can supply the domain's policy, and thus have that
policy applied to them.

> syntaxes would be useful for other things anyway).

  Sounds reasonable.  That way we can kill two birds with one stone:

  DNS will supply information that "our policy is at URI foo", and
that policy can be fetched via HTTP, FTP, or supplied in-line in SMTP,
if there's an "in-line SMTP" URI.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Wed, 23 Jun 2004 13:22:31 -0400

Hadmut Danisch <[email-masked]> wrote:
>   keys secret.

  The keys don't have to be that secret if they can change
periodically.

>   false records.

  How?

>   records. Do you thing thats practical and feasible?

  People already control access to their MTA's.  I don't see this as
much of a problem.

>   at all? Why not simply signing the message itself?

  The message is not the SMTP transation.

  Putting the policy exchange into the SMTP transaction is
semantically similar to using STARTTLS with a client certificate
signed by a CA, and then supplying the policy in-line in the TLS
tunnel.  All of the key exchange issues devolve to getting the key for
a root CA, and using it to verify another certificate.

  The difficulty with that approach is the repudiation of certificates
is hard.  There's no easy way to distribute certificate revocations,
unlike putting ephemeral keys into DNS, where they can expire as
quickly as you want.

  Alan DeKok.

---

From: Hadmut Danisch <[email-masked]>
Date: Wed, 23 Jun 2004 19:34:10 +0200

>  The keys don't have to be that secret if they can change

This sounds to be a lot of overhead and very error-prone.
How often do you want to change them? Every day?
Reduce the DNS TTL to 24 hours? How would you cope
with the latency? I don't think you can do it often enough
to defend against stolen key and slow enough to not
cause false rejections at the same time. Maybe you'd need
a sliding window of several keys,e.g. you generate one
key per week and, with respect to the delay cause by
DNS propagation,  the last three keys are considered valid.
You need this, because MTAs can delay mails up to 10 days.

So once a spammer got your key he has about three weeks
time to use it for spamming.

>>  start to write  routines to collect the keys to generate
Exactly the same way they do steal PINs, TANs, passwords, codes
etc. today. Worms already contain elaborated procedures to collect
and reveal secrets kept on the hard disk. Looking for  such a
anti-spam-key is just one more key.

>  People already control access to their MTA's.  I don't see this as

Not really. If they did, we would not have open relays.

Even if 99,9% of MTAs were secure enough. (And that's a
far too high estimation!) How many domains exist? A billion?
How many MTAs? How many stolen keys are 0,1 % of them?
That's enough for spamming.

And how would you do the synchronous update of the
DNS zone and the MTA? I do not see how this could be easily
and automatedly be done in all cases.

>  The message is not the SMTP transation.

Fully agreed. But if you use secret keys anyway, wouldn't it
be better to sign the message? Getting rid of all those
forwarding problems?

regards
Hadmut

---

From: John Levine <[email-masked]>
Date: 23 Jun 2004 19:12:17 -0000

>> What about putting the MARID data in-line in SMTP via an extension?

The obvious problem is that there's no way to tell if the in-line data
is real without making another transaction back to the sender's domain
to check.  If we have to use a separate TCP session to fetch a
possible cachable chunk of XML, the right way to do that is with http
and just fetch the policy document.  It's defined, it's standard, it's
debugged, it's available, and it works.

You need a web server to do that, but I would think it'd be a lot
easier to set up a little web server than to deploy a yet to be
invented overloaded extension to SMTP.

Alternatively, the sender could put some kind of signed thing into the
message that the recipient could check against a static set of signer
keys, but we have that, too.  It's S/MIME.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"A book is a sneeze." - E.B. White, on the writing of Charlotte's Web

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 23 Jun 2004 13:15:41 -0700 (PDT)

> debugged, it's available, and it works.

I agree with you in general (and with Hadmut), but would point out that 
http is also primarily one-key lookup protocol (which has been extended a 
lot by means of cgi parameters) and retreiving entire policy document is 
not the best idea if we're talking about it being so large that its 
better off at the http server. 

The best (in my opionion) is to actually work on specifications on new 
policy document such that it can be deployed over existing pre-built 
protocol. Protocol should be such that it works both over udp and over 
tcp (udp preferred if client and server support it) and returns particular 
data asked based on multiple lookup keys. My preference is something like 
what CRISP, which is XML specification that should go along with BEEP 
transport. Other XML possibility which make it easier to deply is one 
level up based on SOAP with full protocols being either (or all of) SOAP 
over HTTP and SOAP over BEEP and SOAP on UDP. Non-XML protocol option is 
LDAP (its supposed to be possible to do it over UDP, but I've never seen 
anybody implement it) and possibly something else I don't even know about.
 
> invented overloaded extension to SMTP.
Yes, agreed. And this was also already discussed at asrg before.

> keys, but we have that, too.  It's S/MIME.
There is still a need for client to reguarly retrieve CRLs. So we can 
never completely remove the necessity to do call-back lookup.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "John R Levine" <[email-masked]>
Date: 23 Jun 2004 21:09:49 -0400

> better off at the http server.

You can encode any query you want into a URL.  I don't see that as a
problem.  You want to work in the mailbox, time of day, number of
messages, phase of moon, just define some conventions to map the
parameters you want into the URL.

> protocol.

I entirely agree.  That's why I keep saying http.  Do experiments with
http, then if we find that we're looking up lots of tiny documents, and
they'd fit into single packets, and the lookup is a bottleneck, then it'd
makes sense to consider some lighter weight protocol.

Until then, I don't see any point in defining a policy protocol until we
have some experience defining and using policy documents.  At this point
we don't even know who'll be publishing them and how a mail recipient will
decide who to ask.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.