Pete Resnick wrote:
I am perfectly happy with Murray's original (and now, revised) text.
(Nits still being discussed are entirely up to the WG.) I am not happy
with Charles's text. Particularly:
On 7/7/11 5:08 AM, Charles Lindsey wrote:
Recall that, when multiple instances of a given header field are
present, they are signed starting with the last one and working
upwards (section 5.4.2). This DKIM feature can be deployed to mount a
variety of attacks against the email system. In some, the attacker is
also the signer, signing the second of some duplicated field on
behalf of his own domain, whilst hoping that some lenient MUA will
display only the first. In others, a genuine signature from the
domain under attack is obtained by legitimate means, but extra header
fields are then added, either by interception or by replay.
It seems like this text is tailor-made to obfuscate who is doing the
attacking and who is being attacked. It's this distinction that I think
is the most important to make, and the above text simply does not
clarify; it muddies the waters. DKIM can only be "deployed to mount a
variety of attacks" if the recipient has already made the fatal mistake
of assuming that the existence of a cryptographically valid signature
*means* that the message is reliable and from a known "good" sender. You
could have a longer and more detailed discussion in the document about
how broken it is for a recipient to do such a thing, and put *that* into
the security consideration, but I don't think it's necessary. The above
can only obfuscate that very important point, making it out as if it's
something in the DKIM signing/verifying process that caused the problem.
pr
I don't quite follow. There seems to be this effort to "remove a bad"
(erroneous or not) connotation about DKIM (for some rubber stamping
reason) when the facts are there is a strong possibility of a problem
only because DKIM raises the bar or something in regards to "email."
I strongly believe the mail industry never had a problem (at least I
don't ever remember an exploit) because most, if not all, was designed
to read mail for one FROM. There is no need to continue reading,
reading from the bottom either, normal sequential reading for the
From: field found. In other words, I doubt any software has a
COLLECTION concept for From fields. Why when there there was no need
for it. So the first one read was the one shown or the one used for
gateway transformations, which is a strong point here - not every
backend mail system stores mail in pure RFC x822/5322 format.
I would like to see one software, any software that holds a structure
for multiple froms? I doubt it exist.
Hence, that is why we never saw the problem.
But now with DKIM, it changes the issues somehow. DKIM allows for a
perfect cryptographic valid signature for any bits it ignorantly signs
and that includes all headers. In fact, I know of one API that
without any IMPLEMENTATION controls - it will, by default, sign all
headers, including if there exist multiple From: headers.
You MUST recode the API if you want to invalidate the signing of an
illegal RFC5322 message with multiple froms. Ironically, the same API
did make a change to check for multiple froms during the verification
process, but it did nothing on the signing side. I guess that might
be ok when the design presumption is that the implementation of the
API will make sure the input is valid during signing.
In any case, I think the protocol should include both a functional and
technical requirement for a ONE FROM criteria during the signing and
verification process.
I agree with Doug that at some point DKIM will have some "meaning" for
validity and I think it is best that DKIM doesn't continue signing or
verify an illegal RFC5322 message even if the mechanism allows for a
valid abstract signature.
Finally, in my implementation opinion, the only thing that makes me
wonder is how far do we go to address the legacy verifiers who are not
going to check for multi-from message. Do we add the h=From*n+1 kludge?
Well, we decided that as long as we allow the h= setting to be
flexible for the operator, then they can add it (we add it by default)
as a short term solution. In the long term, I don't think it has to
be used, but then again, I am strongly basing that that most DKIM
implementations will eventually use a ONE FROM RULE criteria for both
signing and verifying.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html