Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02

From: SM <[email-masked]>
Date: Tue, 19 Oct 2010 14:18:44 -0700

Hello,

I commented on draft-ietf-dkim-rfc4871bis-01 previously ( 
http://mipassoc.org/pipermail/ietf-dkim/2010q4/014696.html ).

draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871.  RFC 5672 updates 
RFC 4871.  Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) 
Signatures -- Update" document not being obsoleted by this document?

In the Introduction Section:

   "DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message by associating the domain with the
    message."

Dave proposed a change to add a RFC 1034 reference in that sentence.

    DomainKeys Identified Mail (DKIM) permits a person, role, or
    organization that owns the signing domain to claim some
    responsibility for a message  [RFC5322] by associating the domain
    name [RFC1034] with the message.

I suggest adding a reference to RFC 5322 in there to make it clear 
what "message" is.

As I mentioned previously, in Section 3.3:

    "In general, sha256 should always be used whenever possible."

That text was in RFC 4871 too as part of the informative note.  Could 
it be removed to avoid any dilution of the SHOULD in the "Signers 
MUST implement and SHOULD sign using rsa-sha256" sentence?

In Section 3.3.3:

      "The practical constraint that large (e.g., 4096 bit) keys may not
       fit within a 512-byte DNS UDP response packet"

Could a normative reference to RFC 1035 be added in that sentence?

       The practical constraint that large (e.g., 4096 bit) keys may not
       fit within a 512-byte DNS UDP response packet [RFC1035]

I'll mention it again; in Section 3.5 for the d= tag:

    "Internationalized domain names MUST be encoded as described in
     [RFC3490]."

And i= tag:

    "Internationalized domain names MUST be converted using the steps
     listed in Section 4 of [RFC3490] using the "ToASCII" function."

Is there a reason why this working group requires that a document 
with an intended status of "Draft Standard" should have a normative 
reference to a RFC that has been obsoleted?

In Section 5.3:

   "Similarly, a message that is not compliant with RFC5322, RFC2045
    correct or interpret such content."

I do not understand that sentence.

  "Therefore, a verifier SHOULD NOT validate a message that is
    not conformant."

That sounds like good advice.

According to draft-ietf-dkim-implementation-report-03, the 
interoperability and testing event was held in 2007.  Was the above 
requirement tested during that event?  If this working group wants to 
add such a requirement, I suggest setting the intended status of 
draft-ietf-dkim-rfc4871bis to "Proposed Standard".

In Section 5.5:

   "Verifiers MUST be capable of verifying signatures even
    if one or more of the recommended header fields is not signed
    (with the exception of From, which must always be signed)"

Is the last "must" a requirement?

draft-ietf-dkim-rfc4871bis has an informative reference to RFC 
5451.  I note that the draft uses the "X-Authentication-Results" 
header field line.

Regards,
-sm

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 21 Oct 2010 13:48:51 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Tuesday, October 19, 2010 2:19 PM
> To: [email-masked]
> Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> 
> Hello,
> 

That sounds right to me.

> I suggest adding a reference to RFC 5322 in there to make it clear

I forget; does the email architecture document talk about the difference between a DNS domain and an ADMD?  This was an issue during the IESG evaluation of Authentication-Results and I seem to recall it being a place to which readers could be referred to learn the difference.  Maybe changing "domain" to "DNS domain" would be appropriate, and also changing the RFC1034 reference to point at RFC5598?

> MUST implement and SHOULD sign using rsa-sha256" sentence?

The OpenDKIM stats shows that SHA1 is still in very widespread use, both by domain counts and by aggregate message counts.  Trying to force DS to talk only about SHA256 would mean alienating half or more of the current install base, and we felt that was probably a bad idea.

>        fit within a 512-byte DNS UDP response packet [RFC1035]

Seems reasonable to me, though I don't think it needs to be normative since that text is discussion rather than protocol specification.

> reference to a RFC that has been obsoleted?

I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it.  I seem to recall one of the other co-authors looking into it and finding this was acceptable, but I don't recall.  Dave, can you comment?

> I do not understand that sentence.

XML error.  Dave already posted what that was supposed to be.

> draft-ietf-dkim-rfc4871bis to "Proposed Standard".

I don't recall it being tested specifically.  And I don't have a good sense about whether the addition of this normative requirement would require a recycle or not.  I defer to those more experienced than me.

> Is the last "must" a requirement?

No, I think it's simply an informative back-reference to another specified requirement.  Maybe changing "must always" to "always has to" would clear that up.

> 5451.  I note that the draft uses the "X-Authentication-Results"

Yes, that should be fixed.

Thanks,
-MSK

---

From: "John R. Levine" <[email-masked]>
Date: 21 Oct 2010 21:22:12 -0400

> I can't remember the disposition of this, but I think the problem is that we want to use ToASCII while no current (i.e. not obsolete) document contains a definition of it.  I seem to recall one of…

I suggest the two places that refer to IDNS say

  Internationalized domain names MUST berepresented as A-labels as
  described in [RFC5891].

That's a current standard, and A-labels are what ToASCII was supposed to
produce.

R's,
John

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 18:49:25 -0700

> That's a current standard, and A-labels are what ToASCII was supposed to

That's a technical change to the DKIM Signing specification.  Plus, it 'fixes' a 
problem that has not yet been reported for DKIM.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 20:44:20 -0700

On 10/21/2010 1:48 PM, Murray S. Kucherawy wrote:
>> draft-ietf-dkim-rfc4871bis-02 obsoletes RFC 4871.  RFC 5672 updates RFC
>> 4871.  Why is the "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures --
>> Update" document not being obsoleted by this document?
>
> That sounds right to me.

+1

>> "DomainKeys Identified Mail (DKIM) permits a person, role, or organization
>> that owns the signing domain to claim some responsibility for a message by
>> associating the domain with the message."
>>
>> DomainKeys Identified Mail (DKIM) permits a person, role, or organization
>> that owns the signing domain to claim some responsibility for a message
>> [RFC5322] by associating the domain name [RFC1034] with the message.
>>
>> I suggest adding a reference to RFC 5322 in there to make it clear what
>> "message" is.
>
> I forget; does the email architecture document talk about the difference
> between a DNS domain and an ADMD?  This was an issue during the IESG

Well, it /defines/ ADMD (eg, Section 2.3) and merely uses dns domain names 
(section 3.3).  It does not compare or contrast the two uses of the word 
'domain'.  ADMD has a bit of extra verbiage to make it substantially different 
from DNS domain.  It still has the word domain because folks seemed to want to 
use it, rather tenaciously.

> evaluation of Authentication-Results and I seem to recall it being a place to
> which readers could be referred to learn the difference.  Maybe changing
> "domain" to "DNS domain" would be appropriate, and also changing the RFC1034
> reference to point at RFC5598?

Couldn't hurt.

>> That text was in RFC 4871 too as part of the informative note.  Could it be
>> removed to avoid any dilution of the SHOULD in the "Signers MUST implement
>> and SHOULD sign using rsa-sha256" sentence?
>
> The OpenDKIM stats shows that SHA1 is still in very widespread use,

After the latest round about SHA1, I believe where we landed is to keep the 
relevant text in the spec as is.  No changes.

>> "The practical constraint that large (e.g., 4096 bit) keys may not fit
>> within a 512-byte DNS UDP response packet"
>>

It's now in the pending -03 version.

>> The practical constraint that large (e.g., 4096 bit) keys may not fit
>> within a 512-byte DNS UDP response packet [RFC1035]
>
> Seems reasonable to me, though I don't think it needs to be normative since
> that text is discussion rather than protocol specification.

Sorry.  I'm not understanding what text to add, or where.

>> "Internationalized domain names MUST be converted using the steps listed in
>> Section 4 of [RFC3490] using the "ToASCII" function."
>>
>> Is there a reason why this working group requires that a document with an
>> intended status of "Draft Standard" should have a normative reference to a
>> RFC that has been obsoleted?
>
> I can't remember the disposition of this, but I think the problem is that we
> want to use ToASCII while no current (i.e. not obsolete) document contains a
> definition of it.  I seem to recall one of the other co-authors looking into
> it and finding this was acceptable, but I don't recall.  Dave, can you
> comment?

We've had no call to change that aspect of the specification.  While the formal 
status of the cited document (that defines toAscii) might have changed, the 
algorithm has not been a problem for DKIM and still works, and the cited 
document is still accessible.

My concern is that shifting the reference to the newer document also requires 
changing the DKIM technical specification and that that will require recycling 
at Proposed, for merely bureaucratic reasons rather than from any technical need.

>> "Therefore, a verifier SHOULD NOT validate a message that is not
>> conformant."
>>

Given the mathematics of a signature, I believe the formal RFC 5322 conformance 
of the message is actually irrelevant to DKIM.

It's highly relevant to other processing engines, but not DKIM.

In other words, if a DKIM signature validates, it validates.  That's the /only/ 
test or assurance that is needed.

>> According to draft-ietf-dkim-implementation-report-03, the interoperability
>> and testing event was held in 2007.  Was the above requirement tested
>> during that event?  If this working group wants to add such a requirement,
>> I suggest setting the intended status of draft-ietf-dkim-rfc4871bis to
>> "Proposed Standard".
>
> I don't recall it being tested specifically.  And I don't have a good sense
> about whether the addition of this normative requirement would require a
> recycle or not.  I defer to those more experienced than me.

I believe it was not explicitly (or probably even implicitly) text.  I'll repeat 
that I think it is actually irrelevant.

>> In Section 5.5:
>>
>> "Verifiers MUST be capable of verifying signatures even if one or more of
>> the recommended header fields is not signed (with the exception of From,
>> which must always be signed)"
>>
> No, I think it's simply an informative back-reference to another specified
> requirement.  Maybe changing "must always" to "always has to" would clear
> that up.

On reflection, I am going to suggest some slightly different wording:

    Except for the requirement to have a signature cover the From header field, 
the list of header fields that determines signature validity is determined only 
by the list in the h= parameter.

d/

-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 22 Oct 2010 00:08:23 -0400

>> RFC 3490 is obsolete, replaced by 5890 and 5891. When they rewrote it 
>> they made the language descriptive rather than prescriptive, and an 
>> A-label is the new name for what was the output of ToASCII.

> My understanding is that they actually changed the behavior of the 
> 'subroutine'.  Nothing in the switch to 5322 from 2822 changes any behaviors 
> for DKIM.

Of course it does.  The message syntax in 5322 is ever so slightly 
different from 2822, so the set of valid messages over which DKIM is 
defined is slightly different, too.  It didn't change very much, but 5890 
didn't change very much either.  It mostly tightened up rules for 
rejecting invalid input, got rid of dependencies on a particular version 
of Unicode, and fixed a few arcane bugs.

> The toAscii routine still works for us.

Sort of.  IDN2008 handles more recent versions of Unicode than IDN2003 
does and allows some joiner characters that IDN2003 ignored, so ToAscii 
willl fail on some valid current IDNs.

I see that on the IDNA list they're arguing about this exact issue for a 
revision of http cookies, so I guess that whatever they do, we can do.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: SM <[email-masked]>
Date: Thu, 21 Oct 2010 21:31:04 -0700

Hi Murray,
>That sounds right to me.

It does not sound right to me.

>I forget; does the email architecture document talk about the 
>difference between a DNS domain and an ADMD?  This was an issue 
>during the IESG evaluation of Authentication-Results and I seem to 
>recall it being a place to which readers could be referred to learn 
>the difference.  Maybe changing "domain" to "DNS domain" would be 
>appropriate, and also changing the RFC1034 reference to point at RFC5598?

A proper comparison of the two requirea more than one sentence.  I'll 
keep it short; ADMD is about administrative authority whereas a DNS 
domain is of a list of labels.  The reference to RFC 1034 is a 
pointer for the reader to find out what is meant by "domain 
name".   When we talk about domain names, as in DNS, we refer to 
specifications about DNS.  If the question comes up in an discussion 
about email (within the IETF), consideration is given to whether it 
is about email delivery or about the domain name space and resource 
records; and the discussion is punted to the appropriate group.

Changing the reference to RFC 5598 may cause problems in other parts 
of the draft.

>both by domain counts and by aggregate message counts.  Trying to 
>force DS to talk only about SHA256 would mean alienating half or 
>more of the current install base, and we felt that was probably a bad idea.

Maybe I did not explain what I meant correctly.  I am not arguing for 
the document to talk only about SHA256.  I'll quote the text from Section 3.3:

   "DKIM supports multiple digital signature algorithms.  Two algorithms
    are defined by this specification at this time: rsa-sha1 and rsa-
    sha256.  Signers MUST implement and SHOULD sign using rsa-sha256."

As you can see, there is a SHOULD for signing using 
rsa-sha256.  Signing with rsa-sha1 is not forbidden.  I am not in 
favor of alienating half or more of the current install base.

>Seems reasonable to me, though I don't think it needs to be 
>normative since that text is discussion rather than protocol specification.

That text is not normative.  Having the reference as normative means 
"please read the following document to understand what is written in 
this document".

>I can't remember the disposition of this, but I think the problem is 
>that we want to use ToASCII while no current (i.e. not obsolete) 
>document contains a definition of it.  I seem to recall one of the 
>other co-authors looking into it and finding this was acceptable, 
>but I don't recall.  Dave, can you comment?

It would be highly unusual to use such a reference.  I will most 
likely nit about that.

>I don't recall it being tested specifically.  And I don't have a 
>good sense about whether the addition of this normative requirement 
>would require a recycle or not.  I defer to those more experienced than me.

The addition of the normative requirement would complicate 
matters.  I mentioned the recycle as it would keep matters 
simple.  It would be premature to determine which status is the most 
appropriate.

>No, I think it's simply an informative back-reference to another 
>specified requirement.  Maybe changing "must always" to "always has 
>to" would clear that up.

That's fine.

Regards,
-sm

---

From: "John R. Levine" <[email-masked]>
Date: 22 Oct 2010 00:39:31 -0400

I've gone through 4871bis-02 again to look for sections that don't deal 
with correctness, robustness, or interoperability and have some suggested 
changes.  I also noticed a few editing nits on the way. None of this is 
intended to be contentious, or to change any of the bits on the wire.

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.

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.

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.

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.

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.

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.

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"

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.

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

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]"

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:

          INFORMATIVE NOTE: The Local-part of the "i=" tag is optional.
 	 It can include the domain part without the Local-part of the
 	 identity.

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

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

Page 27, x= first informative note: delete, doesn't help robustness or
  interoperability.  (Neither does x= but that's a lost battle.)

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?

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.

Page 29, sec 3.6.1, first pp: delete, since it doesn't help robustness
  or interoperability.

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

Page 29, description of g=: address -> AUID, in four places.  The i=
  value is an AUID, not an address.

Page 30, h=: suggest moving the language about which algorithms a verifier
  supports to page 13 as suggested above.

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.

Page 35, first pp, last sentence: delete it, or else get rid of l=

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
   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.

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."

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."

Page 38, pp starting "Signers SHOULD NOT": delete?  Recent discussion
  suggests that people don't follow this.

Page 39, first line: "failed" -> "invalid" to be consistent

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.

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.

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."

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

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.

Page 46, pp after note: bad -> invalid, good -> valid, for consistency

Page 46, informative note: faulty -> invalid, for consistency

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.

Page 47, 3rd pp: "should be performed" -> MUST be performed.  This is
  not optional.

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.

Page 48, Sec 6.1.1, informational note: Delete second sentence, unless
  we really think we're that bad at proofreading.

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.

Page 51, informative implementation note: tells verifier to edit the message,
  delete last two sentences.

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?

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?

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.

Regards,

---

From: Dave CROCKER <[email-masked]>
Date: Thu, 21 Oct 2010 21:41:46 -0700

On 10/21/2010 9:31 PM, SM wrote:
>> difference between a DNS domain and an ADMD?
...
> pointer for the reader to find out what is meant by "domain

right.  I think that clear references and careful use of terminology should 
suffice.  The specification need not be a tutorial on the differences between 
two technologies or RFCs that it cites.  Correct?

> "please read the following document to understand what is written in

I am confused.  In a technical specification a normative reference provides 
material that is part of the technical detail.  It's not for background or 
explanation.  It is for /use/.

> It would be highly unusual to use such a reference.  I will most

Interestingly, the document that made it historical refers to it for more than a 
reference saying it has been replaced.  That is, it makes a substantive comment 
on it.

We need to be careful not to let odd formalities get in the way of basic pragmatics.

  d/
-- 

   Dave Crocker

---

From: "John R. Levine" <[email-masked]>
Date: 22 Oct 2010 01:04:05 -0400

> Interestingly, the document that made it historical refers to it for 
> more than a reference saying it has been replaced.  That is, it makes a 
> substantive comment on it.

I caught up on the back and forth on IDNA.  The incompatibilities between 
IDN2003 and IDN2008 are limited to the encoding of two uncommon 
characters, which the IDNA group think is not a big deal, hence their 
decision not to change the xn-- prefix.  Really, we should change the 
references to the current standard.

R's,
John

---

From: Barry Leiba <[email-masked]>
Date: Fri, 22 Oct 2010 10:27:55 -0400

> references to the current standard.

I'm inclined to agree, but let me get a reading from the IESG on
whether this will affect the standards-track status, and how they
would handle the obsolete reference if we didn't make the change.

Barry, as chair

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Oct 2010 10:56:30 -0700

> From: SM [mailto:[email-masked]]
> Sent: Thursday, October 21, 2010 9:31 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> 

I understand your point, but what I'm saying is that the DNSDIR people, on reviewing RFC5451, were not satisfied with that line of reasoning, resulting in a DISCUSS from the OPS AD until I went back and indicated for every use of "domain" which thing I meant.  I'm simply trying to avoid that.

> favor of alienating half or more of the current install base.

Then I guess I don't understand the basis for the suggested change.  The citation you made here doesn't seem to conflict with the "should use sha256 whenever possible" advice, since a normative SHOULD basically means "always, unless you have a very good reason not to do so".

---

From: SM <[email-masked]>
Date: Fri, 22 Oct 2010 14:16:24 -0700

Hi Dave,
At 21:41 21-10-10, Dave CROCKER wrote:
>right.  I think that clear references and careful use of terminology 
>should suffice.  The specification need not be a tutorial on the 
>differences between two technologies or RFCs that it cites.  Correct?

Yes.  A specification is not a tutorial.

>I am confused.  In a technical specification a normative reference 
>provides material that is part of the technical detail.  It's not 
>for background or explanation.  It is for /use/.

A normative reference provides material which the reader must read to 
understand the specification.  In this case, it is a way to have a 
reference to STD 13 which covers domain name concepts and implementation.

>We need to be careful not to let odd formalities get in the way of 

I am fine with that as long as there is a good reason.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Oct 2010 17:39:49 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of John R. Levine
> Sent: Thursday, October 21, 2010 9:40 PM
> Subject: [ietf-dkim] Commments and clarifications to 4871bis-02
> 

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.

>   change to "Signers SHOULD NOT reuse a selector with a new key" or

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.

>   this language just encourages code that won't interoperate.

I don't see anything on page 11 about EAI, nor any informative notes.

>   h=, but I think this is a better place to put it.

Works for me.

> that people still use sha1, so we should document it, but is there any

I defer here to the security community.  I don't think they're as hard on SHA1 as they are on MD5, for example.

>   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.

>   content length, perhaps based on other criteria"

Agree.  (Though I see that on page 18)

>   which has not (I hope) ever been implemented.  At least not on

Yep.  I'm split between leaving this for an appendix of wacky DKIM ideas or just leaving it to obsolete history.

> increased other than arithmetically?

I imagine it was meant as "sequentially", but I agree that no adverb there is really needed.

>   represented as A-labels as described in [RFC5891]"

Yes and yes.

>   my AUIDs refer to web scripts and mailing lists.

Actually I think that whole sentence is redundant to the earlier text of the paragraph.

>  	 It can include the domain part without the Local-part of the

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"?

>   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.

>   end of the paragraph suggesting that the verifier can remove text

Yup, and maybe copy it to an implementation appendix.

>   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?

>   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.

>   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

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 20 that I suggested deleting.

Not sure what you're saying here; did you want that last sentence out?

>   value is an AUID, not an address.

Concur.

>   supports to page 13 as suggested above.

Worked for me back there too.  :-)

>   make all unknown selectors be revoked.

Concur.

> Page 35, first pp, last sentence: delete it, or else get rid of l=

Concur.

>    domain in the signature's AUID ("i=" tag of the signature) is

s/is/can be/

>    absent, the domain of the AUID MUST be the same as, or a subdomain

Looks right to me.

>   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.

>   what it says is "we don't know what if anything an AUID will be used

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.

>   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.

>   reads his mail which could be months.

What's "the maximum delivery time"?  Are you talking about "x="?  (I suspect not...)

> 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.

>   invalidating the signature."

Works for me.

>   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.

>   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.

>   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

Works for me.

>   an implementation can do whatever it wants.  Does not help robustness

Yup.

>   we really think we're that bad at proofreading.

I always thought that was weird too.

>   one key record per selector with undefined results otherwise to improve

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"?

>   delete last two sentences.

Yeah, I'd be OK with moving all of these tricky ideas to an appendix.

>   nothing wrong with recording results that way, but is the verifier the

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.

>   Why is the verifier paying any attention to unsigned header fields at

Yep.

>   AUID is the primary identifier, how is this section useful?  Suggest

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

---

From: John Levine <[email-masked]>
Date: 23 Oct 2010 01:38:47 -0000

>I don't see anything on page 11 about EAI, nor any informative notes.

Oops, that's page 12, the note about UTF-8 at the bottom.

>Agree.  (Though I see that on page 18)

Right, it's p.18.  (It was pretty late, one number starts to look a lot
like another.)

>Actually I think that whole sentence is redundant to the earlier text of the paragraph.

OK with me.

>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"?

Sure.

>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.

Hmmn.  Do we want to say "DKIM doesn't identify individual users so
don't try to make it do that?"  If so, it's probably better to put
somewhere closer to the top.

>I'm not even sure I understand that remark.  Can someone remind us of
 what it's trying to say?

We had long arguments in which some people argued that one could keep
bad guys from replaying messages by making the x= time short enough.

>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.

This is one of those places where I don't know how much we can change
without the IESG deciding to recycle.  Just saying to use QP isn't
adequate, since then you couldn't tell whether =BD is the 1/2 symbol
in 8859-1, the oe ligature in 8859-15, or those three characters.  My
inclination is just to take it out, since at this point the 5322 rules
say that any non-ASCII should already be MIME-encoded in the headers
that z= copies so there shouldn't be anything to downcode.

>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.

There was a bunch of quite hypothetical discussion of other ways to
represent and serve keys, none of which ever amounted to anything.
That's why I'd rather wait until there actually are other kinds of
keys before describing what they are.

>Not sure what you're saying here; did you want that last sentence out?

It's saying that if, 1.0 != 1, so much for increasing arithmetically.
This language is fine.  (My preferred order is 5, 2, 8, 9, 4, 7, 6, 3,
1, 0, which is of course alphabetical order in French.)

>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.

If we agree that's an explicit output, that'd be a rather large change
to the spec. My DKIM verifier Mail::DKIM just says yes or no, perhaps
with a note about whether failure was DNS related or one of the hashes
not matching.

>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.

OK.

>Verifiers SHOULD treat invalid signatures as though they were not

OK.

>What's "the maximum delivery time"?  Are you talking about "x="?  (I suspect not...)

RFC5321 recommends "at least 4-5 days" as the time to keep retrying a delivery
before giving up.  That's what I had in mind.

>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.

We give that advice in other places, so we can probably do without it here.

>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.

OK.

>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"?

Unless someone has an implementation that does something with multiple
TXT records, I'd prefer to change the text to match the code.

>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.

There was a long argument here, too.  One side argued that subdomains
are entirely at the mercy of parent domains since that's how
delegation works, the other argued that there are cut points like
gTLDs where the parent is different from the subdomain, although they
admitted there is no reliable way to tell where those cut points are,
nor exactly what the problem was.  (You can probably tell which side I
was on.)

>Thanks for the fine-toothed comb!

You're quite welcome.

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 23 Oct 2010 00:20:19 -0400

On Friday, October 22, 2010 09:38:47 pm John Levine wrote:
> without the IESG deciding to recycle.  

I think we should decide what's best for the long term health of the protocol 
and then let the IESG worry about recycling or not.  Getting it right is more 
important than advancing up the standards ladder.

Scott K

---

From: SM <[email-masked]>
Date: Fri, 22 Oct 2010 22:42:16 -0700

>   the editing language.  I'd suggest the latter.

I suggest the latter.

>   change to "Signers SHOULD NOT reuse a selector with a new key" or

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

>   this language just encourages code that won't interoperate.

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

>   h=, but I think this is a better place to put it.

Yes.

>that people still use sha1, so we should document it, but is there any

Yes.

>   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.

>increased other than arithmetically?

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

>   no relation to any user.  Or perhaps rewrite as:

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

>   sentence, since it doesn't help robustness or interoperability

See above.

>   end of the paragraph suggesting that the verifier can remove text

Yes.

>   page 20 that I suggested deleting.

I suggest keeping it.

>   than just "a verification header" ?

My previous comment about this was ignored.

>Can you say SHOULD NOT in something informative?

No.

>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

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

---

From: SM <[email-masked]>
Date: Fri, 22 Oct 2010 22:46:41 -0700

Hi Murray,
At 10:56 22-10-10, Murray S. Kucherawy wrote:
>I understand your point, but what I'm saying is that the DNSDIR 
>people, on reviewing RFC5451, were not satisfied with that line of 
>reasoning, resulting in a DISCUSS from the OPS AD until I went back 
>and indicated for every use of "domain" which thing I meant.  I'm 
>simply trying to avoid that.

And that is what the suggested change is for as it has a reference to 
what "thing" the document is talking about.

>Then I guess I don't understand the basis for the suggested 
>change.  The citation you

This is covered in John Levine's message.

Regards,
-sm

---

From: "John R. Levine" <[email-masked]>
Date: 28 Oct 2010 14:12:37 -0400

I've adjusted my DKIM verifier so that it fails if a message contains more 
than one of any of these headers:

 	From Sender Subject Date To Cc MIME-Version
 	Content-Type Content-Transfer-Encoding

It doesn't check whether they're signed, just counts the headers.  I'll 
let you know if anything awful hap
NO CARRIER
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html