Thanks for your comments. Responses inline:
At 10:10 AM 11/2/2004 +0000, David Woodhouse wrote:
I'm assuming that the random spaces in the middle of words like 'w orms'
in the first paragraph of the introduction are a systematic error due to
the way the text is edited and rendered into text form?
No, that was just inadvertent spacebar hits while I was editing the file in
emacs on my PC. I spellchecked the document when I thought I was almost done,
but of course it took more to finish the revision than I expected.
In §3.2 you suggest that if the the null key check indicates that all
legitimate messages are signed, "the verifying MTA SHOULD discard
unsigned messages. It MAY generate a "bounce" message when doing so."
I'd like to rephrase that. Let's not say that you "MAY" accept and
bounce, thereby almost certainly spamming innocent third parties with
your bounce to a faked message. Let's instead say that you "SHOULD NOT"
accept and bounce. That still leaves the same leeway for people who
really _want_ to make themselves part of the problem by implementing
accept-and-bounce to do so, while making it clear that they shouldn't.
I thought for a while about what words to use there. I was trying to emphasize
that the decision to not accept a message doesn't necessarily mean that a
bounce is generated. But I like your wording because it more actively
discourages the generation of a bounce.
I'd also like to change 'discard' to 'reject'. IMHO one should never
just discard mail. You do your utmost to _reject_ it if you don't like
it, and in exceptional circumstances you may only work that out later so
you may _occasionally_ need to accept-and-bounce. But neither 'discard'
nor 'bounce' are good suggestions in the general case.
The problem with 'reject' is that it will likely cause the preceding MTA, which
is likely to not be mailsig-aware. If we're really trying to suppress bounces,
you need to accept and silently discard.
Although you're quite specific about using quoted-printable, your
canonicalisation seems to make no mention of character sets. I would
suggest that you MUST convert all character sets in text parts
(including the headers) to UTF-8 before converting to QP and creating or
verifying a signature (although you don't have to _send_ as UTF-8).
I think the only place we explicitly require quoted-printable is with respect
to copied headers. But this should only be an issue if the message coming in
is not already RFC 2822 compliant, because the RFC 2047 encoding will ensure
that there's nothing that we need to convert (except equals signs and double
quotes). I'm not sure about the requirement to convert to UTF-8 first. Would
it be better if we require RFC 2047 encoding of the headers, and perform that
encoding if it's not already there?
Also, have you done any analysis of the cost of the 'body length count'
in practice? Given a length of N bytes, is the recipient expected to
perform a full cryptographic check on each range of N bytes within the
received email? I had assumed that a simpler rolling checksum would be
needed to locate potential matches in the larger text before the more
expensive check was done... was I being overly defensive in that?
The body length count always starts at the beginning of the body (following
canonicalization, if any). No matching is required. Is that unclear from the
spec?
In §5.2 you say "the From header MUST be included; the Sender header
MUST also be included [if appropriate]". You omit any reference to
Resent-From/Resent-Sender, which likewise MUST also be included, surely?
I'm still lacking information on how and where Resent-From/Resent-Sender are
used, so I ignored them in the spec. If we need support for them, then, yes,
they also need to be included. I don't see a lot of Resent-* in the messages I
get; is this an important case I'm ignoring? Or can we get users of Resent-*
to also set Sender?
Although you sanely eschew wildcard DNS entries elsewhere, you suggest
their use in §6.1.3 for publishing a null key policy. This is a prime
example of why wildcard records are no use -- you'll only actually see
the record for any domain name which _doesn't_ have any other RRs....
i.e. you'll only be managing to publish your wildcard null key record
for those domain names which sane people wouldn't be accepting mail from
anyway, because they have no way of receiving mail by virtue of having
neither A, AAAA nor MX records.
Agree that's broken. We discovered that problem just as we were publishing the
spec. We have an alternative in mind that solves the subdomain attack and
doesn't involve wildcards.
In §6.2 you say that "If the verifying MTA is able to verify the public
key of the sender and check the signature on the message as the message
is received, the MTA MAY reject the message...". Since you've already
qualified it with "if the MTA is able..." I'd definitely want to see
that change to "SHOULD reject the message", or at least make it clear
that the MTA SHOULD NOT accept the message if it's going to be rejected
(and hence bounced) later.
The context here was to point out that messages could be rejected "on the fly".
SHOULD seems a little strong since this can still occur as a result of a
message body being inadvertently modified in transit. But I agree that if the
recipient domain's policy is to reject the message at some point, it SHOULD
reject it on the fly if possible. I'll try to come up with some wording that
conveys that.
You speak of the possibility of a message such as '4yx Unable to verify
signature - key registration server unavailable'. It occurs to me that
the process of trying to fetch a key may take a while, and it's done
after the DATA are sent and while the sender is waiting for our
acknowledgement. RFC2822 says we should be as quick as possible about
that... so have you considered an SMTP extension to provide the IIM key
as part of the MAIL FROM command, so it can be fetched in advance?
Interesting optimization; no, I hadn't considered that because I was trying to
avoid SMTP changes. We would still need to be fairly quick in cases where the
sending MTA didn't support the new option. One idea, although it introduces
some message delay, is that if the key verification result didn't answer
quickly enough, we might 4xy the message after some timeout, but continue
verifying the key and cache it for next time.
If you don't mind, lets queue these ideas for later. There are some more
fundamental issues we need to deal with first.
§7.4 isn't quite correct in its portrayal of RFC2822 requirements w.r.t
the Sender header, I think. It says that a forwarder MUST remove any
pre-existing Sender header, but if there's a Sender header and we
resubmit the message adding our own Resent-{From,Message-ID,To} headers,
we aren't obliged to remove the old Sender header are we? We should
leave it intact. In §7.4 you should discuss this type of 'forwarding'
also, and make it clear that a signature for the Resent-From: address
must be included.
Again, I'd like to have someone explain to me how Resent-* headers are used in
practice, and in what situations, before I add support for them to the draft.
In §7.6. 'Third-party Message Transmission.' you say that a verifying
MTA 'SHOULD' mangle the From field by including information from the
Sender field. Can we change that to 'MAY'? It's a hack to work around
what some MUAs currently display, and it's not something that should be
done in general. We should make that clear, surely? In fact it's phrased
a lot better in §4.6 already.
Where is it phrased better? I don't have a section 4.6.
It's definitely a hack. I made it a SHOULD because IMO visibility of the
signing address to the end user is essential to the security of email
authentication. If the message has a From header of
<security(_at_)bigbank(_dot_)com> but has a Sender header of
biff(_at_)sdfcdnasdocnaspf(_dot_)com [some throwaway domain], the user really
needs to know that. Absent the security consideration, I would definitely have
made this a MAY.
You should add a new subsection 9.1.5 to discuss the potential denial-
of-service attack posed by large messages with a bogus length count,
forcing the recipient to hunt for the signed part in the message.
No hunting is required. If the signed content isn't at the beginning of the
body, it doesn't verify.
Again, thank you for your thorough review.
-Jim