ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Commments and clarifications to 4871bis-02

2010-10-22 19:42:45
-----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