-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of John R. Levine
Sent: Thursday, October 21, 2010 9:40 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Commments and clarifications to 4871bis-02
Overall: in several places such as the informative note at the top of
page 18, the language says that the verifer produces an edited
version of the message. We either should say that the edited message
is part of the verifier's output, probably in section 2.2, or delete
the editing language. I'd suggest the latter.
Based on a pure API perspective, I agree. The verifier's output is a yea/nay
about each signature along with possibly some hooks to ask about what the
signatures looked like. It doesn't output an altered form of the message.
However, I'd be fine with sticking this into Section 8 or an appendix
discussing implementation choices.
Page 11, informative operations note at the end of section 3.1: Either
change to "Signers SHOULD NOT reuse a selector with a new key" or
delete it.
Can you say SHOULD NOT in something informative?
If you can't, then I'd make this into a regular paragraph instead of an
informative note, and apply the SHOULD NOT language. If you can, your change
is fine with me.
Page 11, informative implementation note at the bottom of the page:
Delete it. If we want to support EAI, we should support EAI, but
this language just encourages code that won't interoperate.
I don't see anything on page 11 about EAI, nor any informative notes.
Page 13: section 3.3: should it also say "Verifiers MUST implement
both sha1 and sha256"? It says so on page 20 in a= and page 30 in
h=, but I think this is a better place to put it.
Works for me.
Page 13, informative note at the bottom of the page: Delete. I realize
that people still use sha1, so we should document it, but is there any
reason to encourage it.
I defer here to the security community. I don't think they're as hard on SHA1
as they are on MD5, for example.
Page 14, sec 3.3.3, first paragraph. I don't understand what this pp
is telling me to do. In the second sentence, what does "for
long-lived keys" mean? A week? A decade? And what's the life of
the key? The time from when it's published in the DNS until it's
deleted? The time that signers use it, regardless of time in the
DNS? Suggest trimming this down to say signers MUST use at least
1024 bits, verifiers MUST handle 512 to 2048 bits, and leave it at
that. If we think a 512 bit signature is no good, we should say so.
My first inclination is to preserve the sentiment and refer to a policy of
frequent key rotation, but that still isn't very specific.
Thus, my second inclination is to agree.
Page 17, informative implementation note at the top: Delete message
editing language "or remove text that appears after the specified
content length, perhaps based on other criteria"
Agree. (Though I see that on page 18)
Page 17, second informative informative implementation note in the
middle: suggest deleting the whole thing. It's a recipe for disaster
which has not (I hope) ever been implemented. At least not on
purpose.
Yep. I'm split between leaving this for an appendix of wacky DKIM ideas or
just leaving it to obsolete history.
Page 20, informative note under v=: Delete. Has a version number ever
increased other than arithmetically?
I imagine it was meant as "sequentially", but I agree that no adverb there is
really needed.
Page 22, discussion of d=: "Internationalized domain names MUST be
represented as A-labels as described in [RFC5891]"
Page 23, discussion of i=: "Internationalized domain names MUST be
represented as A-labels as described in [RFC5891]"
Yes and yes.
Page 24. first pp: delete "or MAY choose other means of representing
its users." An AUID need have no relationship to any user. Some of
my AUIDs refer to web scripts and mailing lists.
Actually I think that whole sentence is redundant to the earlier text of the
paragraph.
Page 24, informative note: suggest deleting, again because AUID need have
no relation to any user. Or perhaps rewrite as:
INFORMATIVE NOTE: The Local-part of the "i=" tag is optional.
It can include the domain part without the Local-part of the
identity.
Since there are a lot of reasons one might wish to leave out the local-part
(don't know, don't want to say, don't feel like it), I'm fine with being this
simplistic. Maybe what you have, but tack onto the end "if the signer is
unable or unwilling to specify a value there"?
Page 24, informative discussion: delete everything after the second
sentence, since it doesn't help robustness or interoperability
I could live with it being out, but I like it in there if only to document our
deliberations so others later won't have spend the energy to go down the same
path.
Page 25, informative implementation warning: remove language at the
end of the paragraph suggesting that the verifier can remove text
from the body.
Yup, and maybe copy it to an implementation appendix.
Page 27, x= first informative note: delete, doesn't help robustness or
interoperability. (Neither does x= but that's a lost battle.)
I'm not even sure I understand that remark. Can someone remind us of what it's
trying to say?
Page 28, z= last pp: it says that header fields " SHOULD be converted
as described in MIME Part Three [RFC2047]." That document describes
encoding of specific character sets such as ISO-8859-1. What
character set is it supposed to use?
Interesting. I suppose it should be just basic DKIM-quoted-printable
conversion, meaning this whole paragraph can go except perhaps to indicate that
even eight-bit data can be thus represented.
Page 28, sec 3.6, second pp: delete, since in fact the only key server
we describe is the DNS. If some future document adds other key servers,
that would be an appropriate time to add language about them.
I think it's actually implicitly redundant to the next paragraph that describes
the portions of the signature which indicate how and where to retrieve the key.
So yeah, I'm fine with it going.
Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness
or interoperability.
I had to think about this one for a while. Would it even be appropriate to
describe this as the DNS Text Representation, rather than just Text
Representation? We might do it a different way in HTTP without XML, for
example.
Page 29, description of v=, last sentence: compare that to the note on
page 20 that I suggested deleting.
Not sure what you're saying here; did you want that last sentence out?
Page 29, description of g=: address -> AUID, in four places. The i=
value is an AUID, not an address.
Concur.
Page 30, h=: suggest moving the language about which algorithms a verifier
supports to page 13 as suggested above.
Worked for me back there too. :-)
Page 33, informative operational note: delete it, since the first
sentence is wrong, and the second sentence is out of scope.
Wildcards work just fine as key records if that's what you want to
do. For example, you could publish a wildcard with an empty p= to
make all unknown selectors be revoked.
Concur.
Page 35, first pp, last sentence: delete it, or else get rid of l=
Concur.
Page 35, sec 3.8: language about "on behalf of its subdomains" is
confusing since we now say the d= domain is the primary identity.
Suggest renaming this section to "Subdomains in AUIDs" and flip the
language around, e.g.:
In some circumstances, a domain may wish to apply a signature with
an AUID that is a subdomain of the SDID. By default, signatures can
contain an AUID that is any subdomain of the SDID. For example, if
a signature's SDID (the domain in the "d=" tag) is example.com, the
domain in the signature's AUID ("i=" tag of the signature) is
s/is/can be/
sub.example.com, or even sub1.sub2.example.com. In order to limit
the capability of such keys when this is not intended, the "s" flag
MAY be set in the "t=" tag of the key record, to constrain the
domain of the AUID. If the referenced key record contains the "s"
flag as part of the "t=" tag, the domain of the AUID ("i=" flag)
MUST be the same as that of the SDID (d=) domain. If this flag is
absent, the domain of the AUID MUST be the same as, or a subdomain
of, the SDID.
Looks right to me.
Top of page 36, first sentence. If we leave in the message editing
stuff, change to "Hence, DKIM's mandatory output to a receive-side
Identity Assessor is a single domain name and a possibly edited
version of the message that has been verified."
I don't like the edited version stuff. I'd prefer it to be positioned as an
explicit indication of what fields and portion of the body were signed.
I imagine "hnamas" in that paragraph should be changed to "has" as well.
Page 36, informative discussion: delete it, since as far as I can tell
what it says is "we don't know what if anything an AUID will be used
for."
I'd rather say that explicitly, even if more concisely. It's better to say
that than say nothing and leave them wondering why we didn't say anything about
it.
Page 38, pp starting "Signers SHOULD NOT": delete? Recent discussion
suggests that people don't follow this.
Agree.
Page 39, first line: "failed" -> "invalid" to be consistent
Actually I find that sentence structure weird. How about:
Verifiers SHOULD treat invalid signatures as though they were not
present in the message.
Page 40, informative operations advice at the top: do we believe this
advice to keep a verification key around until the recipient reads
the message? I think in other discussions we've agreed that the key
should be valid for the maximum delivery time, not until someone
reads his mail which could be months.
What's "the maximum delivery time"? Are you talking about "x="? (I suspect
not...)
Page 42, informative admonition: I don't understand what we're supposed
to do with this advice, which appears to be intended for the authors
of relay MTAs. Perhaps to make this operational, it should warn signers
that signing multiple fields makes it more likely that the signature
will break due to gratuitous reordering, as it says in sec 8.11.
Within context, I take it to be a warning against signing trace header fields
like Received. But I agree that its presentation is a little ambiguous.
Page 44, end of section 5.5: suggest changing that warning to "SHOULD
NOT specify a body length of zero, since this allows a hostile party
to replay the message with an entirely different body without
invalidating the signature."
Works for me.
Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather
than just "a verification header" ?
I think the idea is that RFC5451 is one example of an annotation system, so "a
verification header field such as the one described in RFC5451" would probably
be fine.
Page 46, informative implementation note: the previous pp just said not
to depend on signing order, and this note tells you how to guess what
the order was. Huh? Delete the note.
Works for me. I'm not sure what information this is supposed to impart,
inasmuch as I can't think of an example that isn't already covered.
Page 46, pp after note: bad -> invalid, good -> valid, for consistency
Yup.
Page 46, informative note: faulty -> invalid, for consistency
Yup.
Page 47, first pp: why would a verifier make note of invalid
signatures? There's no subsequent step that uses them. Suggest
deleting that sentence unless we can explain what to do with them.
Yup.
Page 47, 3rd pp: "should be performed" -> MUST be performed. This is
not optional.
Works for me.
Page 47, Sec 6.1.1, informative implementation note: delete it, since
an implementation can do whatever it wants. Does not help robustness
or interoperation.
Yup.
Page 48, Sec 6.1.1, informational note: Delete second sentence, unless
we really think we're that bad at proofreading.
I always thought that was weird too.
Page 49, item 4: does any implementation really cycle through multiple
key records? The one I use (Mail::DKIM) doesn't. Suggest limit of
one key record per selector with undefined results otherwise to improve
interoperability.
Ours barks if more than one TXT comes back without checking any of them. That
said, what about saying "MUST process one, MAY process the rest or MAY return
an error if the first one was no good"?
Page 51, informative implementation note: tells verifier to edit the message,
delete last two sentences.
Yeah, I'd be OK with moving all of these tricky ideas to an appendix.
Page 51, sec 6.2: more message editing, adding and deleting headers. There's
nothing wrong with recording results that way, but is the verifier the
right place to do it?
If we've defined a tight DKIM scope as the verifier, then no. But if the
verifier comprises the DKIM module plus the goop around it that actually does
something with the result, then it could add a header field or even do other
stuff.
Page 52, second to last pp: more message editing, suggest deleting entire pp.
Why is the verifier paying any attention to unsigned header fields at
all?
Yep.
Page 62, sec 8.13: since we've agreed that the SDID rather than the
AUID is the primary identifier, how is this section useful? Suggest
deleting it.
Hmm. The AUID isn't primary, but that doesn't mean there aren't possibly
interesting semantics there, especially since we're not talking about the
local-part. Since it's informative, I don't see that it steers anyone wrong to
leave it in there, again relying on my earlier feeling that I'd rather opt to
relay some non-normative discussion than nothing so that later people aren't
wondering why we weren't totally silent on the matter.
Thanks for the fine-toothed comb!
-MSK
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html