ietf-dkim
[Top] [All Lists]

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

2010-10-23 00:57:29
At 21:39 21-10-10, John R. Levine wrote:
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.

I suggest the latter.

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.

As it is informative, it is better to avoid the "SHOULD NOT".

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.

That depends on the text in Section 3.5 on which I commented previously.

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.

Yes.

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.

Yes.

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.

The long-lived keys is related to the time it takes to succumb to an 
attack.  I would say that the validity is as long as the keys can be 
used to verify a message.

Page 20, informative note under v=: Delete.  Has a version number ever
increased other than arithmetically?

I suggest keeping this as version numbering is always a problem.

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.

Page 24, informative note: suggest deleting, again because AUID need have
  no relation to any user.  Or perhaps rewrite as:

I suggest not touching those two to avoid rehashing previous discussions.

Page 24, informative discussion: delete everything after the second
  sentence, since it doesn't help robustness or interoperability

See above.

Page 25, informative implementation warning: remove language at the
  end of the paragraph suggesting that the verifier can remove text
  from the body.

Yes.

Page 29, description of v=, last sentence: compare that to the note on
  page 20 that I suggested deleting.

I suggest keeping it.

Page 45, second pp of section 6: shouldn't this refer to RFC5451 rather
  than just "a verification header" ?

My previous comment about this was ignored.

At 17:39 22-10-10, Murray S. Kucherawy wrote:
Can you say SHOULD NOT in something informative?

No.

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?

"x=" should not be considered as a way to mitigate replay attacks.

Verifiers SHOULD treat invalid signatures as though they were not
present in the message.

Verifiers SHOULD ignore invalid signatures ...

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.

You argued for standardization of the header field.

Regards,
-sm 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html