Subject: [ietf-dkim] DKIM vs. MIME

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 24 Apr 2010 21:22:05 -0700

Someone on the opendkim-users list has pointed out that DKIM signatures are being invalidated when re-mailed through one particular MLM that rewrites Content-Type: so that its value is all lowercase.  Obviously this is a problem for DKIM since even "relaxed" requires nothing other than spacing changes in header field values; however RFC2045 says that the interpretation of Content-Type: values is case-insensitive.  Thus, at least to consumers of that header field, DKIM is doing something "wrong".  In any case, it was suggested on that list that "relaxed" header canonicalization be adjusted to accommodate this.

The response is probably obvious: DKIM operates at a level below the semantics of the header fields it signs, i.e. closer to SMTP than to MIME, and so it hasn't, and shouldn't have, knowledge about header field interpretation.  I suspect this isn't something we consider a problem that needs fixing in the spec.

Just identifying this as another point of interest with respect to MLM BCP stuff we might wish to produce (which is starting to sound like a more urgent matter than it did before).  Maybe I'll start drafting something.

-MSK
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 25 Apr 2010 04:55:09 -0000

>Someone on the opendkim-users list has pointed out that DKIM
>signatures are being invalidated when re-mailed through one
>particular MLM that rewrites Content-Type: so that its value is all
>lowercase.  Obviously this is a problem for DKIM since even "relaxed"
>requires nothing other than spacing changes in header field values;
>however RFC2045 says that the interpretation of Content-Type: values
>is case-insensitive.  Thus, at least to consumers of that header
>field, DKIM is doing something "wrong".  In any case, it was
>suggested on that list that "relaxed" header canonicalization be
>adjusted to accommodate this.

Although I see the point in this particular case, it seems to me that
it would be a hopeless rathole to try to catalog and account for all
of the semantics of every possible header line and the set of possible
modifications to each header that do or do not make a semantic
difference.  Looking at the RFCs, I can't tell whether the boundary
string in Content-Type: is supposed to be case sensitive, but the
addresses in To:, From:, Cc;, and so forth certainly are, and I
wouldn't want to get into an argument about whether the Subject: line
is.

R's,
John

PS: Needless to say, this supports my observation that the number of
list managers that don't break DKIM signature is insignificant.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 24 Apr 2010 22:17:17 -0700

> -----Original Message-----
> From: John Levine [mailto:[email-masked]]
> Sent: Saturday, April 24, 2010 9:55 PM
> To: [email-masked]
> Cc: Murray S. Kucherawy
> Subject: Re: [ietf-dkim] DKIM vs. MIME
> 

That's my perspective as well.

> list managers that don't break DKIM signature is insignificant.

For now, anyway.  It's obvious to me, though, that a lists BCP from this WG would be an extremely good idea.

---

From: [email-masked]
Date: Sat, 24 Apr 2010 23:04:41 -0700 (PDT)

> wouldn't want to get into an argument about whether the Subject: line

It's a hopeless rathole for a variety of reasos, but boundary parameters aren't
one of those reasons.

Boundary parameters are case sensitive. This is explicitly stated in
RFC 2045 section 5.1 and probably in other places as well.

More generally, media type parameters default to case sensitive; however, many
definitiosn override this default either explicitly (e.g., charset) or
implicitly (e.g., version parameters whose syntax only allows numbers and
punctuation).

But since new media types are defined all the time, and old ones are revised,
to say nothing of the types people just make up and never register. As such,
you cannot possibly code something that gets case normalization right in
general. So yes, it's hopeless.

				Ned

---

From: SM <[email-masked]>
Date: Sat, 24 Apr 2010 23:45:22 -0700

At 21:22 24-04-10, Murray S. Kucherawy wrote:
>lowercase.  Obviously this is a problem for DKIM since even 
>"relaxed" requires nothing other than spacing changes in header 
>field values; however RFC2045 says that the interpretation of 
>Content-Type: values is case-insensitive.  Thus, at least to 
>consumers of that header field, DKIM is doing something "wrong".  In 
>any case, it was suggested on that list that "relaxed" header 
>canonicalization be adjusted to accommodate this.

If I am not mistaken, it's a MTA and not a MLM that did that modification.

>The response is probably obvious: DKIM operates at a level below the 
>semantics of the header fields it signs, i.e. closer to SMTP than to 
>MIME, and so it hasn't, and shouldn't have, knowledge about header 
>field interpretation.  I suspect this isn't something we consider a 
>problem that needs fixing in the spec.

I would categorize it as operating close to the (signer/verifier) 
boundaries to get around in-transit modifications to the mail format.

Regards,
-sm

---

From: Alessandro Vesely <[email-masked]>
Date: Sun, 25 Apr 2010 13:05:59 +0200

On 25/Apr/10 08:04, [email-masked] wrote:
>>> field, DKIM is doing something "wrong".  In any case, it was suggested on that list that "relaxed" header canonicalization be adjusted to accommodate this.

I'd rather define new canonicalization algorithms than tamper with 
existing ones.

>> [...] but the addresses in To:, From:, Cc;, and so forth certainly are

> [...] But since new media types are defined all the time, and old ones are revised, to say nothing of the types people just make up and never register. As such, you cannot possibly code something that gets case normalization right in general. So yes, it's hopeless.

An alternative would be to err on the other side: a "mellowed" 
canonicalization, that respects only the fields and entities whose 
meaning and encoding is well known and stable, so as to allow some 
kind of forgeries rather than accidental breaking.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 25 Apr 2010 13:35:49 -0000

>If I am not mistaken, it's a MTA and not a MLM that did that modification.

Right, it's Courier.  DKIM has now been a published RFC for three
years, and was in development for several years before that, and this
is the first time we've run into this sort of incompatibility.

Under the circumstances, the correct response is clearly to fix
Courier so it doesn't mess with the mail headers it presents to
milters rather than to modify DKIM and change every DKIM
implementation in the world to work around it.

R's,
John

PS: I think you'll find this is not the first time Mr. Courier has
provided this sort of unasked help to his users.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 27 Apr 2010 00:03:27 +0200

> I'd rather define new canonicalization algorithms than tamper with 

Agreed.

> kind of forgeries rather than accidental breaking.

The main question here is: how often are DKIM signatures invalidated 
during transit, what is the exact cause (case- or similar modifications 
of header fields?) and how much do we gain by defining a new 
canonicalization algorithm? Do we have any real-world figures about this 
'accidental breaking'? How many DKIM signatures on average survive two 
MTA hops? How many three hops? Etc.? Is there a relationship? And if 
they get broken, is that due to changing case of header fields or due to 
other changes? And if the number of broken signatures caused by transit 
systems (apart from the mailing list issues, which bring their own 
problems) is non-negligeable, is there anything that we can do to 
improve things?

/rolf

---

From: Douglas Otis <[email-masked]>
Date: Mon, 26 Apr 2010 16:13:31 -0700

> during transit, what is the exact cause (case- or similar 
> modifications of header fields?) and how much do we gain by defining a 
> new canonicalization algorithm? Do we have any real-world figures 
> about this 'accidental breaking'?  How many DKIM signatures on average 
> survive two MTA hops? How many three hops? Etc.? Is there a 
> relationship? And if they get broken, is that due to changing case of 
> header fields or due to other changes? And if the number of broken 
> signatures caused by transit systems (apart from the mailing list 
> issues, which bring their own problems) is non-negligeable, is there 
> anything that we can do to improve things?
Rolf,

With most mailing-lists, nearly all signatures will be damaged whenever 
the subject line is modified, or something has been appended to the 
message body.

Any strategy that attempts DKIM settings to permit such modification 
exposes recipients relying on DKIM to be taken in by simple exploits.  
Such exploits might be used either enable convincing spamming or 
phishing schemes, which weakens the value DKIM otherwise would have 
afforded.

A safer strategy would be to permit DKIM domains a means to grant 
exceptions en-mass for mailing lists known good at excluding spamming 
and phishing, with hopefully  subject lines and mailfrom or reply-to 
lines being changed to it clear the message was distributed by the 
mailing-list.  Efforts at making such distribution transparent only 
invites abuse.

-Doug