Subject: [ietf-dkim] Today's jabber notes...

From: Stephen Farrell <[email-masked]>
Date: Thu, 22 Feb 2007 20:25:59 +0000

..attached. Please check to see if something you care about
was discussed since there weren't enough people present
to be confident of rough consensus.

Stephen.

The DKIM wg had a jabber session on Feb 22nd 1600-1700 UTC.

Taking part were
	Stephen Farrell (co-chair)
	Eric Allman
	Paul Hoffman
	Mike Thomas

jabber log: http://www3.ietf.org/meetings/ietf-logs/dkim/2007-02-22.html

Since there were so few present, the conclusions drawn must be tentative.
Please comment if you disagree with something in these notes.

The agenda was:

a) revuew suggested milestone dates
b) SSP related issues from the tracker
c) Prague meeting items
d) AOB

a) Milestone dates
------------------

The milestone for the SSP protocol WGLC was too early in July so the revised
milestones became:

Mar 2007	WG last call on SSP requirements 
May 2007	WG adoption of SSP protocol draft 
Nov 2007	WG last call on SSP protocol 
Nov 2007	WG last call on overview document 

If there's no debate on this on the list I'll foward that to Russ in a week
(Mar 1).

b) Issues from tracker
----------------------

We reviewed the issues from the tracker. Some of these had already been
considered at the 20061107 jabber session or in San Diego, but we went through
them anyway.

The list is at:

https://rt.psg.com/Search/Results.html?Order=ASC&Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50&OrderBy=id&Format=

Summarising the outcome:

1356, 1357, 1362, 1363: Mike to check with Dave Crocker that
      these can now be safely CLOSED.
1360: CLOSED barring list objections
1364: Mike to check with Dave again, thinks this can be CLOSED.
1365: Eric to check on list if we have consensus to drop 5.3 requirement 2,
1383: CLOSED - we decided that in San Diego
1386: Not clear what the requirement is - Mike to mail PHB asking for 
      clarification
1398: Eric to raise this on the list - want clarification from Frank
1399: Mike to add a requirement like "the protocol MUST be crystal 
      clear as to when SSP must be invoked" and then CLOSE this
1402: Stephen to raise on the list & add to Prague agenda
1408: Jabberers wanted to CLOSE this one with no change

If you raised an issue, or if you care about one, please check that the
suggested disposition above is ok.

(Eliot, if no-one objects in the meantime, can you handle the tracker changes
implied above in a week's time?)

Mike is aiming to have a -03 I-D out before the cutoff (Mar 5) with the hope
that we can start WGLC on that (even if there may be an issue or two remaining
open at that stage).

c) Prague agenda items
----------------------

Stephen will send a mail with a suggested agenda in a couple of days. 

It'll include slots for discssion on:

- issue 1402 & WGLC on ssp-reqs generally
- when/what BCP type work should be do (suggested by Eric)

d) AOB
------

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

---

From: Douglas Otis <[email-masked]>
Date: Thu, 22 Feb 2007 14:59:46 -0800

On Feb 22, 2007, at 12:25 PM, Stephen Farrell wrote:

> ..attached. Please check to see if something you care about was  
> discussed since there weren't enough people present to be confident  
> of rough consensus.

Sorry for missing the jabber.  I will not be able to attend the  
Prague meeting, which is perhaps another reason to celebrate. ; )

It would be nice to ponder how an originating domain owner can  
designate or authorize their signing domain.  This was item #1360  
listed as closed barring objections.  Such a mechanism avoids then  
universally defining a minimum domain depth list, as required in the  
base draft.  Is anyone interested in further defining this concept?   
A rough outline was started as the DOSP draft.  Without a mechanism  
for originating domains to authorize different signing domains, just  
defining whether all, some, or none offers very little protection,  
especially when EAI is embraced.

Philip's has a valid issue, but it really should be solved within the  
key structure.  That seems like water under the bridge at this time.

Time will tell how well DKIM does.  My fingers are crossed, and I  
hope for the best.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Feb 2007 13:36:36 +0100

> https://rt.psg.com/Search/Results.html?Order=ASC&Query=Queue%20%3D%20'dkim'%20AND%20(Status%20%3D%20'open'%20OR%20Status%20%3D%20'new')&Rows=50&OrderBy=id&Form

Now my last browser sometimes working with https:;//rt.psg.com
also doesn't show it anymore:

"Netscape has encountered bad data from the server".

Please DITCH this ticket system, it is broken.

You could copy the tickets verbatim to the mailing list or another
device supporting plain text US ASCII, http, ftp, or nntp.   The
"trac" Wiki used by the IESG apparently also works.

> 1360: CLOSED barring list objection

Objection: I've no clue what it's about.

> 1364: Mike to check with Dave again, thinks this can be CLOSED.

Objection: I've no clue what it's about.

> 1383: CLOSED - we decided that in San Diego

Objection: I've no clue what it's about.

> 1398: Eric to raise this on the list - want clarification from Frank

IIRC that was rejected, folks want some "send no mail" signing policy.
The rest was editorial.

> 1408: Jabberers wanted to CLOSE this one with no change

Objection: I've no clue what it's about.

> please check that the suggested disposition above is ok.

I can't.  It's okay if nobody wants to fix the ticket system,
as a consequence please stop to use it.  I've reported that
issue several times now, should I send it as a formal appeal
to the IESG ?

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Feb 2007 13:22:27 +0000

Hi Frank,

I've asked Eliot to see if there's a way to export all of the
tracker text. I can't find one. (If anyone else has a problem
with this site, can you let me know, on or off list. AFAIK,
Frank is the only one.)

But you can also go back through the list archive. I believe
Eliot posted the tracker number for each issue as he created the
tracker entry, in the relevant thread. I've copied the names
of the entries below as well to help speed that up for you.
There are also the meeting minutes where some slides were
presented, and the jabber logs, so I believe the information is
there if you go looking, without the tracker.

Do let me know if you still have problems with specific issues,
but as a working assumption, I would guess that 6 or so days is
enough time to get that done, i.e. I assume that you only really
object if we hear back from you on specific issues.

As to the tool more generally, feel free to bring it up wherever
you think. The site appears to host about 40 or so IETF-related
queues, so I've no idea how many people you're asking to make a
change, but its probably a fair few so you may well have lots of
fun there.

Personally, I'd have no problem with other tools, but I reckon
that for ssp-reqs its a bit late in the day to switch. If you
want to suggest/host something else for our next document feel
free to say so on the list and we'll consider it.

Regards,
Stephen.

1356    What is the purpose of SSP? new dkim    Nobody  0
     [email-masked]   5 months ago        5 months ago    0
1357    SSP: Clarity among the usage scenarios  open    dkim    Nobody  0
     [email-masked]   5 months ago        5 months ago    0
1360    ssp-requirements-01 // Designated Signing Domain Scenario 
missing   open    dkim    Nobody  0
     [email-masked]    5 months ago        5 months ago    0
1362    SSP: Problems with Scenario 4: Resent   open    dkim    Nobody  0
     [email-masked]   5 months ago        5 months ago    0
1363    SSP: Discover "requirement" open    dkim    Nobody  0
     [email-masked]   5 months ago        5 months ago    0
1364    Generic requirements for SSP, v1.   open    dkim    Nobody  0
     [email-masked]   5 months ago        5 months ago    0
1365    SSP: typos  open    dkim    Nobody  0
     [email-masked]    5 months ago    5 months ago    5 
months ago    0
1382    (SSP) New resource record type  new dkim    Nobody  0
     [email-masked] 4 months ago        4 months ago    0
1383    fate of ssp-reqs draft...   open    dkim    Nobody  0
     [email-masked]   4 months ago        4 months ago    0
1386    Downgrade attack    open    dkim    Nobody  0
     [email-masked] 4 months ago        4 months ago    0
1398    (No subject)    open    dkim    Nobody  0
     [email-masked]    3 months ago        3 months ago    0
1399    clarify i= vs. SSP  open    dkim    Nobody  0
     [email-masked]   3 months ago        3 months ago    0
1402    Applicability of SSP to subdomains  new dkim    Nobody  0
     [email-masked]    2 months ago        2 months ago    0
1408    New SSP Requirement - Body Truncation Limits    new dkim 
Nobody  0
     [email-masked]  6 weeks ago     6 week

---

From: <[email-masked]>
Date: Fri, 23 Feb 2007 09:13:16 -0500

"1399: Mike to add a requirement like "the protocol MUST be crystal 
      clear as to when SSP must be invoked" and then CLOSE this"

I may implement check SSP 1st to see if their policy signs or not
I may not use SSP at all
And of course I may check SSP every time I have a DKIM signed message.
Clear as mud
thanks

Bill Oxley
Messaging Engineer
Cox Communications
404-847-6397
-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Thursday, February 22, 2007 3:26 PM
To: ietf-dkim
Subject: [ietf-dkim] Today's jabber notes...

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 23 Feb 2007 10:57:10 -0800

On Feb 23, 2007, at 6:13 AM, <[email-masked]>  
<[email-masked]> wrote:

> I may implement check SSP 1st to see if their policy signs or not I  
> may not use SSP at all And of course I may check SSP every time I  
> have a DKIM signed message.

There are a few factors that should be considered:

1) Limiting transactions to prevent DDoS risks when evaluating  
received messages.

2) Deriving meaningful benefit from the transaction.

Validating specific SMTP clients when limited to A and PTR records  
can not be amplified and are therefore inherently safe.

So:

When processing a signing message, being able to discern associations  
between signing domain and the SMTP client assures the signature is  
not being replayed.
This could be important when the DKKM signature is being used for  
white-listing.

When issuing a DSN, being able to discern associations between the  
MailFrom email address domain and signing domain could assure the  
return message.
This could be important when the message is bounced down stream.

When the signing domain does not match that of any header, then  
adding a means to indicate within the signature on which header's  
behalf the signature was added significantly reduces the number of  
possible authorizations checked.  This assumes that entities such as  
mailing-lists will not always be associated with the From header, and  
that an authorization scheme is also inherently safer than key  
exchanges or domain delegations.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 23 Feb 2007 21:35:50 +0100

Stephen Farrell wrote:
 
> I've copied the names of the entries below as well to help speed
> that up for you.

Thanks, but I only vaguely recall what's what even with complete
titles, these issues are almost six months old.

> you think.

For now I've submitted the issue to [email-masked], after all
it did work until summer 2005 when somebody messed with it.  

> I've no idea how many people you're asking to make a change, but
> its probably a fair few so you may well have lots of fun there.

No, actually it's not funny, it's execessively annoying.  With its
well-known username IETF and password IETF it's no top security site,
no reason why it should be based on new TLS features not supported
by Netscape 3.x or 4.x.  These browerser are good enough to spend
real money at amazon or with paypal.
 
> If you want to suggest/host something else for our next document
> feel free to say so on the list and we'll consider it.

The "trac" Wiki used by the IESG works from my POV (= read access).
 
>      [email-masked]    5 months ago    5 months ago    5

Oops, that was the ticket I recall, where folks wanted "no mail"...
 
>      [email-masked]    3 months ago        3 months ago    0

...but what was that ?  Checking the GMaNe search form:
http://article.gmane.org/gmane.ietf.dkim/6592/match=1398

If that's the issue it was about resent mail originally from an
author claiming to use a "strict" signing policy.  

Frank

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 23 Feb 2007 21:13:12 +0000

> titles, these issues are almost six months old.

The "six months" is a fair point.

If no-one else gets to it before Monday (hint hint) I'll
sort something out for these issues (I would do it, but its
late here now, sorry).

> it did work until summer 2005 when somebody messed with it.  

Sounds like a plan,
S.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 24 Feb 2007 17:22:12 +0100

Stephen Farrell wrote:
 
> If no-one else gets to it before Monday (hint hint)

At least I've now identified a part of #1398.  The general
question is:  "What is the relevant SSP for a mail arriving
without (incl. broken) DKIM signature" ?

Some folks here apparently think that the 2822-From has to
be used.  I'm unconvinced for mails with a Sender or some
kind of Resent-* header fields.  

>> For now I've submitted the issue to [email-masked],
>> after all it did work until summer 2005 when somebody
>> messed with it.
 
> Sounds like a plan,

Yes, for some minutes until they told me that rt.psg.com is
none of their business, and I've to convince [email-masked]
that something with his ticket system doesn't work anymore.

"TLS is if ordinary users have to understand openssl, because
nobody else does"...  <sigh />

Frank

---

From: John Levine <[email-masked]>
Date: 25 Feb 2007 16:16:39 -0000

>also doesn't show it anymore:

Works fine in Firefox on FreeBSD.  Perhaps you should consider a
modest software upgrade.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 27 Feb 2007 08:58:42 +0100

> that something with his ticket system doesn't work anymore.

He actually doesn't manage it.  Rob Austein ([email-masked]) does.  But 
he's unlikely to have a lot of time for this.  These are volunteers - we 
all are.  Had I to do it all over again, I would have chosen roundup - 
in fact I tried moving onto roundup once and ran into some very weird 
problems.

Problems within the tix themselves are probably related to yours truly 
for how I transcribed the information.  This having been said, all the 
information regarding all of the issues can be found in the jabber logs 
or on this list.  If you have specific questions about specific issues, 
I will be happy to research the matter with you.  Just don't hit me with 
dozens at a time.  I also have a day job.

Eliot

---

From: Michael Thomas <[email-masked]>
Date: Tue, 27 Feb 2007 13:36:05 -0800

> kind of Resent-* header fields.  

I think that a distinction can be drawn between what SSP defines,
and how people can use it. We need to define at least one binding 
between a DKIM signature and an outside 2822 origination address.
I think there's pretty good agreement that 2822.From is a very
interesting address. The question you raise, I think, is whether
there are other addresses like Sender, etc. I'll observe that
nothing prevents you from doing an SSP lookup on any address or
domain that you desire, so at some level you are accommodated.
Does there really need to be anything more formal at this point?
I hope not because it likely a deep rathole that in the end isn't
too likely to change anything in the protocol itself (IMO, of course).

		Mike

---

From: Douglas Otis <[email-masked]>
Date: Tue, 27 Feb 2007 14:21:54 -0800

On Feb 27, 2007, at 1:36 PM, Michael Thomas wrote:
> I'll observe that nothing prevents you from doing an SSP lookup on  
> any address or domain that you desire, so at some level you are  
> accommodated. Does there really need to be anything more formal at  
> this point?

Policy can include a scope for the originating field.  The MAILFROM  
might be associated with the signing domain to qualify DSNs. Mailing  
Lists may wish to have one policy for their mailing lists referenced  
by a Sender header scope, and a very different policy for messages  
where their email-address is found within the From header.  Ignoring  
critical subjects postpones the problem, where it is then likely to  
be become a more difficult matter to resolve.

Here is an example of how this scope could be accomplished:

http://tools.ietf.org/wg/dkim/draft-otis-dkim-dosp-02.txt

-Doug