ietf-mailsig
[Top] [All Lists]

RE: Rambings on RFC2822 signatures.

2004-09-19 22:56:47

At 11:58 PM 9/18/2004 -0500, Seth Goodman wrote:

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.

While it would be a good for mailing lists to sign their outgoing messages, I 
don't think we can expect that will happen with all lists on Day One.  In cases 
where it's possible for user signatures to be made to work through mailing 
lists, we can live with those mailing lists being a little slower to adopt 
message signing.  It's also a stronger statement if the user signature as well 
as the mailing list signature verifies correctly -- we can then attribute the 
message to the original sender and not just to the mailing list.

In practice, some canonicalization helps the original user signatures get 
through.  For example, how many people have noticed that this mailing lists 
adds an extra CRLF at the beginning of the body?  I think the benefit of 
getting intact signatures through such lists outweighs the likely abuses of 
such a scheme.



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.

Right.  I vote for requiring no MUA modifications at initial deployment.

-Jim


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