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

["Murray S. Kucherawy" <[e-mail]>]

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of SM
> Sent: Tuesday, October 19, 2010 2:19 PM
> To: [e-mail]
> Subject: [ietf-dkim] Comments on draft-ietf-dkim-rfc4871bis-02
> 
> 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?

That sounds right to me.

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

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?

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

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.

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

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

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

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?

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

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

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

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.

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

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.

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

Yes, that should be fixed.

Thanks,
-MSK

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