Re: A permission to re-sign header

Hi John,

On Fri 18/Apr/2014 04:19:25 +0200 John Levine wrote:
> As I understand it, the original sender puts a hard to forge single
> use token in the message, which the forwarder can include in the
> signed message.
> 
> Since I am lazy, I will reuse DKIM key records and invent a new
> May-Resign header something like this:
> 
> May-Resign: [email protected]; r=ietf.org; s=foo; a=rsa-sha256; \
>    t=1397786669; b=hashhashhash
> 
> This is a permission to re-sign for a message From:
> [email protected], to be re-signed by a mailing list at ietf.org. The
> s= and a= and t= are the same as DKIM, the b= is a signature of a hash
> of the M-R header, similar to the b= signature in a DKIM-Signature.
> 
> The relay includes the M-R header in the DKIM signature.  So now
> we modify DMARC to say that
> 
> IF there is a M-R header with f= that matches the From: line address,
> 
> AND the M-R header is included in a DKIM signature that is signed with
> d= that matches the M-R r=
> 
> AND the M-R signature validates using the s= selector and f= domain
> 
> AND the t= isn't too old (for some meaning of too old)

The difference from the Date: is interesting too, since the latter
field is often visible and signed.

> THEN the message is considered to be aligned.
> 
> Is that the general idea?

Even with the local part (marissam) an M-R is not really hard to
forge, otherwise DKIM-Signature wouldn't have had to include all the
other tags.  If we worry about replay attacks, we can enhance M-R so
that it includes them too.  For example, we could make M-R exactly
like a regular DKIM-Signature, except that it would be a very very
weak one, something that the MLM won't break.  Oh, and of course we
have r=, but then its content could live in its own field.  With such
changes M-R would become quite similar to the joint signatures idea
(http://tools.ietf.org/html/draft-vesely-dkim-joint-sigs-00).

An obvious advantage of following the DKIM specs exactly is to save
developing extra code.  Another advantage is that end receivers who
ignore M-R will just see a valid author signature.  For example, this
message likely passes DMARC validation.

> You could put an M-R header on anything, but if you want to limit it
> to mail to addresses that claim to be mailing lists, you could use the
> same name convention as the DANE S/MIME draft, with hashed mailboxes,
> e.g.:
> 
> <hash of ietf-822>._mayresign.ietf.org TXT "v=MR1; d=ietf.org"
> 
> That says the [email protected] list is signed with d=ietf.org.  If a
> domain contains only mailing lists, you can use a wildcard
> 
> *._mayresign.lists.iecc.com TXT "v=MR1; d=lists.iecc.com"

I'd add fields that won't be modified.  For example:

   v=MR1; d=ietf.org; h=Date:From:To:References:In-Reply-To;

Another tag could be used to say what to do with content, if it will
be fine to sign it using l=original length, or l=0.  The directive for
l= may need to differ depending on the Content-Type (text/plain or
MIME multipart).

Lazy submission servers could stick to the least common signing
directives instead of separately signing each copy of an outgoing
message, in case there are multiple mailing lists among the
recipients.  BTW, would it make sense to mandate some simple
heuristic, for example $addr=~/list/, to save DNS queries?

Ale

_______________________________________________
ietf-822 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-822