Subject: [ietf-dkim] Focusing on 4871bis

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

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

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 22 Oct 2010 09:11:08 -0700

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.

> 1. How to handle a key record with empty "g=" and absent "v=" (section

I thought we had wg consensus to drop g=.

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

> Considerations, explaining the attacks that can be done using this

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.

d/
-- 

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Oct 2010 11:23:16 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 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...
> 

That is also my understanding.

>                          problem into account.</t>

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

Nit: s/will/can/

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

---

From: Hector Santos <[email-masked]>
Date: Fri, 22 Oct 2010 15:15:33 -0400

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

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 11:35:28 -0400

On item number 3. I object that the verifier needs to be doing anything other that verifying that the signed headers and other parts match the signature. Its out of scope to have dkim scurrying about enforcing other RFC's compliance. A policy change would be a better solution. Adding a section to the Security considerations is fine.

 This should be fixed by Policy

---

From: Steve Atkins <[email-masked]>
Date: Fri, 22 Oct 2010 12:54:33 -0700

> "g=" with any value other than "*" or empty, so this can be removed as

This seems like a good change.

> of wildcard TXT records on finding DKIM key records.

Reasonable.

> a non-compliant message.  

I'd object fairly strongly to this, for several reasons.

A DKIM verifier shouldn't be doing anything other than the cryptography
needed  to confirm the signature.

Also, there's a lot of non-5322 compliant mail out there that's perfectly
harmless and wanted. There's also a lot of unwanted or harmful mail
out there that violates 5322.

DKIM signatures allow receivers to track reputation and distinguish 
between those two groups. Crippling DKIM so that it can't be used to
identify the sender for these categories of email seems perverse.

> Add a new section 8.14 to the Security

This seems like a good thing to add.

Cheers,
  Steve

---

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

>                         problem into account.</t>

I realize that 4871 is already too long, but this is too simplistic. 
Wildcards within the _domainkey subtree can do reasonable things, e.g., 
this revokes any unknown key:

*._domainkey.example.com.  TXT     "v=DKIM1; p=; n=revoked"
_adsp._domainkey.example.com. TXT "DKIM=unknown"  ;; override wildcard

I agree wildcards higher up the tree are unlikely to produce useful 
results.

> some significant counter-proposals.

My preference is still that verifiers reject messages that are likely to 
display misleadingly in MUAs, e.g., multiple copies of headers that MUAs 
render one of.  This is a rathole if you consider all the junk a bad guy 
can do in HTML body parts, but at if you insist that the entire body is 
signed, you can at least say that the garbage the user sees is same 
garbage that was signed.

R's,
John

---

From: "Mark Delany" <[email-masked]>
Date: 22 Oct 2010 15:26:40 -0700

> signed, you can at least say that the garbage the user sees is same 

That matches my position - such messages should not verify. Though I
would generalize the "display and MUA" part to "not verify messages
that could mislead subsequence consumers" (where a program is a
consumer too!)

I agree that there is a distinct difference between goop that is part
of the signed message and goop that is not.

Mark.

---

From: Ian Eiloart <[email-masked]>
Date: Mon, 25 Oct 2010 11:20:03 +0100

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

More Nit:
It should probably say either "will produce a response…that is unlikely", 
or "can produce a response…that is not". The former states that the 
problem will occur frequently, the latter says nothing about the frequency, 
but readers may infer that the problem will be infrequent.

-- 
Ian Eiloart
IT Services, University of Sussex
01273-873148 x3148
For new support requests, see http://www.sussex.ac.uk/its/help/

---

From: "John R. Levine" <[email-masked]>
Date: 25 Oct 2010 11:11:34 -0400

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

Forgive me if I repeat myself, but I still don't see anything wrong with 
this:

  *._domainkey.example.com  IN TXT "v=DKIM1; p=; n=revoked"

I'm trying to figure out the clearest way to say that wildcards for key 
records within the _domainkey subtree are OK, while wildcards above it 
cause problems since they are very unlikely to be key records.

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: Eliot Lear <[email-masked]>
Date: Mon, 25 Oct 2010 19:26:12 +0200

On 10/25/10 5:11 PM, John R. Levine wrote:
>
> Forgive me if I repeat myself, but I still don't see anything wrong
> with this:
>
> I'm trying to figure out the clearest way to say that wildcards for
> key records within the _domainkey subtree are OK, while wildcards
> above it cause problems since they are very unlikely to be key records.

Going through my list of arguments I'm coming up short.  Let's see:

1.  Dangerous to other applications.

Nope.  Won't be visible because you are querying what amounts to a
specific application through the use of the label.

2.  Doesn't work with existing records

Nope.  There should be no other existing records, and if so, they're
there to override the wildcard.

3.  ???

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Oct 2010 11:05:55 -0700

On 10/25/2010 10:26 AM, Eliot Lear wrote:
>      Won't be visible because you are querying what amounts to a
...
 >   There should be no other existing records, and if so, they're

Right.

The underscore naming construct really is impressively useful for eliminating 
all sorts of scaling and interaction problems...

d/

-- 

   Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Mon, 25 Oct 2010 11:13:03 -0700

On Oct 25, 2010, at 8:11 AM, John R. Levine wrote:

> Forgive me if I repeat myself, but I still don't see anything wrong with this:
> 
> I'm trying to figure out the clearest way to say that wildcards for key records within the _domainkey subtree are OK, while wildcards above it cause problems since they are very unlikely to be key records.

Do you have an actual use case for that sort of thing, or is it just an example to poke at the "thou shalt not wildcard" wording?

If the former, I've got a mild argument that it's slightly poor practice. If the latter, carry on.

Cheers,
  Steve

---

From: "John R. Levine" <[email-masked]>
Date: 25 Oct 2010 15:30:42 -0400

> Do you have an actual use case for that sort of thing, or is it just an 
> example to poke at the "thou shalt not wildcard" wording?

That example above revokes all unknown keys.

On this message, I've encoded a timestamp and the pid into the DKIM 
signature selector, so I can use my DNS query logs to get an idea of who's 
checking the signatures on what messages.

These may not be fabulous uses of wildcards, but they are at worst 
harmless.  There's a lot of places in the DKIM spec where we say if you do 
so-and-so, you'll be sorry.  I'd like to avoid saying that unless we have 
a good reason to do so, and I only see problems with wildcards above the 
_domainkey label.

Regards,

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Oct 2010 16:59:42 -0400

John,

The reported issue was about *mixed* TXT usage caused by wildcards. 
And it amounted to a large Domain Hosting vendor ONLY offering this 
for spf:

   *.example.com  IN TXT "v=spf1 .........."

And that created mixed query results after adding DKIM related TXT 
records.

The proposed correction text is a) reminder to avoid using them and b) 
for verifiers to be ready to deal with it. i.e. be able to parse for 
the right DKIM related text string.

-- 
HLS

John R. Levine wrote:
>> Do you have an actual use case for that sort of thing, or is it just 
>> an example to poke at the "thou shalt not wildcard" wording?
> 
> signature selector, so I can use my DNS query logs to get an idea of 
> who's checking the signatures on what messages.
> 
> harmless.  There's a lot of places in the DKIM spec where we say if you 
> do so-and-so, you'll be sorry.  I'd like to avoid saying that unless we 
> have a good reason to do so, and I only see problems with wildcards 
> above the _domainkey label.
> 
> Regards,
> ------------------------------------------------------------------------
>