Murray S. Kucherawy writes:
> On Mon, Jun 9, 2014 at 8:59 PM, Stephen J. Turnbull <[email protected]>
> wrote:
>
> > [2] PGP can be worked around by placing the signed body in a separate
> > MIME part from the header and/or footer parts, and DKIM could at least
> > be adapted to decorated subjects using z= and footers using l=,
> > although this would require MUA support to be at all realistic (and if
> > John Levine's most pessimistic assessment of typical users' ability to
> > interpret MUA signals is correct, these workarounds are too dangerous
> > to be used).
> >
>
> The use of z= to get a "secondary" validation of an originator's signature
> makes me uneasy. A failed signature is supposed to fail.
I'm not proposing additional validation. As I've said before, I have
no quarrel with the DMARC protocol or its component protocols (at
least I've not found a reason to dislike it yet), although I strongly
dislike Yahoo!'s policy use of "p=reject".
I'm suggesting the information could be used in the MUA UI. A failed
signature *would* fail. Consider the following scenario:
(1) User posts, MTA DKIM-signs using DKIM-delegate protocol (main
signature signs Subject and body, delegate signature does not).
(2) Mailing list decorates Subject, MTA DKIM-signs all the usual
fields and body, and distributes.
(3) Recipient MTA notes failure of main originator signature but
accepts according to local policy about DKIM-delegate and valid ML
signature, ignoring z=.
Isn't that OK? Now
(4) Recipient MUA has a choice of
(a) Displaying decorated Subject verbatim.
(b) Displaying z= Subject verbatim.
(c) Matching decorated and z= subjects, and discarding mismatched
portions.
(d) As (c), but demphasizing mismatched decorations (eg,
grey-on-grey).
(e) Something else.
I'm suggesting something along the lines of (b), (c), or (d). If the
MUA does (a), it just falls into the abuser's trap, of course. But
that's exactly what would happen now if somebody found a way to suborn
dkim-delegate.
> Back in the DKIM WG days, that was also the consensus position as I
> recall. We also didn't expect MUAs to show which header fields or
> what part of the body were covered by a signature;
Agreed, we cannot expect help from current MUA versions.
> the output of DKIM signature validation is just pass/fail and a
> domain name. Moreover, give a message with multiple signatures
> that passed yet covered different stuff, what could an MUA do that
> wouldn't be utterly confusing to users?
Dunno. I like (4)(d), but I wouldn't be surprised if everybody else
hates it.
But the situation has changed. What could be more confusing than mail
that falls into a black hole because of "p=reject"? People are losing
money over this, you know. Suddenly better MUA handling of security
information may be a competitive advantage or something to puff your
chest over.
> I think back then someone suggested a modified header canonicalization
> method that was the same as "relaxed" except that a single limited-size
> token surrounded by square brackets and followed by a couple of whitespaces
> at most would be omitted from the hash, which would mean Subject tagging
> doesn't invalidate anything.
Yuck. It would work, I guess, but I've seen mailing lists that remove
existing prefixes (Re:, Fwd:) and I can imagine one that removes
"was:" clauses. And that doesn't help with the footer, anyway.
> Finally, in addition to DKIM-Delegate, I posted another draft that
> captures a MIME-sensitive body canonicalization proposal that was
> suggested some time ago by Ned Freed. It may or may not be
> interesting for this effort. It's here:
>
> https://datatracker.ietf.org/doc/draft-kucherawy-dkim-list-canon/
Day job has caught up with me, I'll have to read that later. I'm
making a bet with myself on how far it is from current Mailman
behavior. :-) Thanks for the URL!
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
