ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Focusing on 4871bis

2010-10-22 13:26:28
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Dave CROCKER
Sent: Friday, October 22, 2010 9:11 AM
To: IETF DKIM WG
Subject: Re: [ietf-dkim] Focusing on 4871bis

Synchronization check...

I'm not looking to discuss resolution of these items, but merely verify the
current status of the items within the working group.

On 10/22/2010 8:28 AM, Barry Leiba wrote:
1. How to handle a key record with empty "g=" and absent "v="
(section

I thought we had wg consensus to drop g=.

That is also my understanding.

2. Advice about wildcards in TXT records.
Proposed change: Add a note in section 6.1.2 warning about the effect
of wildcard TXT records on finding DKIM key records.

This is what is in the pending -03 draft in section 6.1.2:

                       <t
                         hangText="NOTE:"> The use of wildcard TXT
records in the
                         DNS will produce a response to a DKIM query
that is
                         unlikely to be valid DKIM key record. This
problem
                         applies to many other types of queries, and
client
                         software that processes DNS responses needs to
take this
                         problem into account.</t>

I haven't heard anything but support for adding that.

Nit: s/will/can/

3. The issue of multiple occurrences of header fields that may only occur 
once.
Proposed change: Add text to section 5.3 recommending that verifiers
check that the message complies with specs, and that they not validate
a non-compliant message.  Add a new section 8.14 to the Security
Considerations, explaining the attacks that can be done using this
exposure.

Those are two different changes.  My own sense is that each has some
controversy, with the first being pretty substantial and with the first having
some significant counter-proposals.

Yes, that's my understanding as well.  (I think you meant "first... second" 
instead of "first... first".)

I'll start a counterproposal to Jim's text in a separate thread.


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