Subject: [Asrg] Re: Body signature subgroup and the forwarding project

From: Bruce Lilly <[email-masked]>
Date: Wed, 27 Jul 2005 16:01:55 -0400

>  Date: 2005-07-26 22:38
>  From: John Levine <[email-masked]>

> Over on the lists where people are working on DKIM and similar
> signature schemes, there's a lot of discussion of message
> canonicalization for signature hashes.  That is, the signature
> involves a hash of the message, but before making the hash, the
> message is cleaned up to make it more likely that the signature will
> still verify after the message passes through a few intermediate mail
> systems, while not letting a bad guy change the message into something
> substantively different.

The root of the problem is various types of modifications made by
SMTP and other transport, and is a well-known problem (see the MIME
RFCs for discussion of a number of issues).  Also see
draft-lilly-extensible-internet-message-format-p01-00.txt and its
companions for a discussion of some of the issues and one possible
approach (in an early stage of development).
  
> Lots of people have strong opinions about various canonicalization
> schemes, but we have precious little data on how messages actually
> change when passing through MTAs.  So I thought a little research
> might be in order.  My plan is to get a bunch of people with different
> MTAs to set up forwarding addresses that forward back to addresses
> here so that I can send them a message, it goes through their MTA and
> returns, and I can now see how the message changed.  My MTA is qmail
> which carefully avoids doing anything to incoming messages other than
> prefixing a Received: header, so it's not hard to isolate the effects
> of the remote MTA.

The issue isn't so much MTAs as network and gateway issues.  E.g. part
of a transport path might permit 8bit or binary transfer while another
part may handle only 7bit content, necessitating conversion by applying
transfer encoding (which isn't permitted if the existing MIME security
multiparts are used, but then if the proposed schemes use something
else, all bets are off).  One or more cycles through X.400 gateways
will result in considerable change (even a single pass in one direction
will cause significant change, but your testing method will only work
for integral numbers of round-trip cycles).  Likewise for gateways to
and from systems that use EBCDIC.  And those that translate to proprietary
mail systems.  Simply passing messages through plain vanilla MTAs in a
pure SMTP context won't reveal much about the problems that can be
encountered in the actual global mail system. 

> I've set up a new subgroup called bodysig.  To subscribe to its list,
> send "subscribe bodysig" to [email-masked].

Poor choice of name?  If you're only looking at the (2822) body and not
including the message header in the hash,
a) you're trying to reinvent the wheel; see S/MIME and PGP/MIME for
   signed messages, and/or RFC 1864 (Content-MD5) field for a hash w/o
   PKI requirements
b) you're doing nothing about phishing and related types of forgery of
   message header fields, which seem to be the most prevalent forms of
   spam at the moment.

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

---

From: John Levine <[email-masked]>
Date: 28 Jul 2005 03:12:02 -0000

>SMTP and other transport, and is a well-known problem ...

>The issue isn't so much MTAs as network and gateway issues. ...

Yes, we all know that.  My goal is to collect some real life data on
what the modifications likely to happen to messages in transit
actually are, to see if there are canonicalizations that will help a
message to survive the transit MTAs that people really use.

> Simply passing messages through plain vanilla MTAs in a pure SMTP
> context won't reveal much about the problems that can be encountered
> in the actual global mail system.

You appear to completely misunderstand the goals of systems like DKIM.
If we wanted S/MIME, we all know where to find it, and we understand
what it does and why it works the way it does.  Little can survive a
trip through an X.400 gateway or for that matter an Exchange server.
Fortunately, X.400 gateways and Exchange servers aren't used as
transit MTAs on the Internet, so they're not very interesting in this
application.

The point of DKIM is the sign messages in a way that will survive
SMTP message transit and be verifiable without a PKI, not to be a
bullet-proof signature for the ages.  Please see the DKIM drafts if
you want to contribute here.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Wed, 27 Jul 2005 23:20:54 -0700

>  Yes, we all know that.  My goal is to collect some real life data on

The IP network certainly imposes no changes on Internet mail.  So I'm not sure 
how "network" can be one of the issues.

As for gateways, those transit to non-Internet mail systems and, of course, 
always do some damage to the message. They might be interesting to study, but we 
have enough to worry about simply within the scope of "pure" Internet mail 
components. 

We simply have the reality that all sorts of noise is imposed on messages as 
they transit various UAs, MSAs, MTAs and MDAs.  

Hence the study you are proposed will set an empirical baseline for exactly what 
the noise (modification) is and probably how common each bit of modification is.

  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net

---

From: Eugene Crosser <[email-masked]>
Date: Thu, 28 Jul 2005 11:32:45 +0400

Just in case, two projects that might be worth looking at in relation to
this one are:

- PGPMoose
- signed USENET control messages

Eugene