ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Focusing on 4871bis

2010-10-22 14:17:59
Based on the discussions, and the recent entry to produce a "counter 
proposal" I would like to ask if we can trying to avoid putting this 
document through another cycle of review vs doing the job right with 
the correct technical information.

For example, IDEALLY per your itemize list:

1) g=

I owe you some data here. I don't know either way other than I have 
not seen (or focused on) any particular importance in the API we are 
using.

2) TXT Records

This requires a "code adjustment" for DKIM DNS clients to parse for 
the v=DKIM1.  This is required for SPF so any implementation that 
supports SPF and wishes to add DKIM will not be at a terrible lost 
with this adjustment.

3) Section 5.4

I think Jim's text makes the technical adjustments.  But personally, I 
still believe there needs to be an "5322.From exception" paragraph 
following the section 5.4 "last header" rule stipulated in the section.

I think the choice has to been made on giving this to "Team A" to get 
the job done tomorrow, or giving this to "Team B" to get the job done 
right even though it may take longer.  I personally do not see why the 
"rush" is trumping the need to do this right.

All this began with a post I made providing Field Experience input 
regarding how a major MTA had already change how it implemented 4871 
with an additional requirement for a single 5322.From and later 
finding out why they did this, leading to the security loophole 
discovery issue.

This MTA's C/C++ open source API is not locked down to a particular 
vendor SMTP software and probably represents many other MTAs DKIM 
implementations, including ours.

I just feel we are wasting time with semantics, as important as that 
may be IETF wise, but I'm afraid it seems to attempt to minimize the 
importance of having a straight forward technical correction 
description which may include code change requirements.

Thanks for listening.

-- 
Hector Santos, CTO
http://www.santronics.com


Barry Leiba wrote:
We seem to be bush-whacking again, rather than staying on the trail.
I don't mind (actually I like) some level of general discussion, but
the chairs would like to focus on our immediate goal for now, so I'm
asking folks to refrain, for the moment, from discussion that isn't
directly addressing the text of 4871bis.

That includes discussion of MUA issues.  We can go back to talking
about that later, but 4871bis is not the place for that, either from a
protocol point of view or from a procedural one.

We have reviews from Jim, SM, and John that the editors are working on
responding to (John's is new enough that I haven't digested it all
yet, and I'm sure the editors haven't either).  We also have three
significant issues that we need to make sure we have resolved
satisfactorily:

1. How to handle a key record with empty "g=" and absent "v=" (section
6.1.2, list item 6).
Proposed change: Remove "g=" altogether, along with all references to
it.  Surveys of what's out there show vanishingly few cases that use
"g=" with any value other than "*" or empty, so this can be removed as
an unused feature.

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.

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.

We ask the editors to consider the latest batches of comments, respond
to them as necessary, produce an -03 version, and post it when they
have it ready.

We ask all participants to speak up specifically about the three
issues above, and let us know whether or not the proposed change is
acceptable.  The editors can post the specific text they're using, if
we have anything to discuss about them.  I believe we have agreement
on the text for number 2, so we should be set on that one.  I haven't
seen a definitive poll about removing "g=" (number 1), but I *think*
we have consensus on that.  Text for number 3 is still being worked
on.

Please start new threads for these discussions, rather than responding
directly to this one, and let's keep the threads for the three items
above separate.

And, again, we particularly ask all participants to refrain from other
discussions that are not specifically about text for 4871bis, so we
can get that document done.

Thanks, everyone.

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





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