ietf-mailsig
[Top] [All Lists]

RE: Rambings on RFC2822 signatures.

2004-09-18 21:58:05

From: David Woodhouse
Sent: Saturday, September 18, 2004 1:10 PM

<...>

The bit with allowing the addition of lines -- or at least being able to
tell that the signed part is still valid despite the addition of lines
(I didn't say that/when the recipient had to _allow_ it) -- is
permissiveness, and that's what seems to be needed to allow most of the
attacks in the field guide you reference.

Speaking personally, I'm most concerned about the additions by mailing
lists, and on text/plain MIME parts.

Mailing lists have to resend it as their own outgoing message anyway.  It is
not really necessary to preserve all the signatures through the re-mailing
process.  The mailing list could validate the signature on the incoming
message, add a header or even body line indicating that fact and sign it on
the way out.  I don't really see the need for the end user to be able to
absolutely validate the identities on mailing list posts at the MUA.  That
sounds like a list function.  Lists do it now by the submitting address
(broken ones use the return-path), so they can switch to validating
signatures instead.

The idea that all MUA's would have to change to deal with displaying
multiple signed parts in different colors, as well as noting parts whose
signature doesn't validate does not bode well for adoption.



I would be more than happy to allow _no_ permissiveness on text/html
parts. Because an attacker could start with '<-- ' and end with ' -->'
followed by a line or two of their own text, and still have a tiny
percentage of 'addition'.

Anyone who wants us to be permissive on text/html should be prepared to
put forward very good arguments that it cannot be exploited. On
text/plain I think we're a lot safer to allow a few lines added at start
and/or end of the original.

I suggest we don't have to allow additions at all, in any of the MIME parts.
The irritating virus scan adverts in the message body are usually put on at
the originating or destination ends, so the signatures can be created after
the addition and validated before any subsequent addition.  Any forwarder
that puts anything in the message body rather than the headers deserves to
have his messages rejected.  That will break virtually any signature scheme,
so what is the motivation to allow this poor practice to continue?

--

Seth Goodman


<Prev in Thread] Current Thread [Next in Thread>