Subject: [ietf-dkim] Montreal agenda, other than base

From: Stephen Farrell <[email-masked]>
Date: Wed, 07 Jun 2006 15:01:41 +0100

Our main Montreal agenda is for a) finishing base and b) kicking
off SSP-related discussions. (a) seems nicely in-hand.

For (b) we'd like to get anyone who'd like an agenda slot to
write up an individual I-D (before the 19th June cutoff!) and then
ask the chairs for however many minutes you'd like. We'll allocate
the time as we see fit however. Your I-D need not contain a fully
worked out proposal for an SSP-like thing, it can simply be a delta
off of the current SSP I-D or anything else consistent with
achieving our charter goals related to SSP.

Our plan is to try get meeting-room consensus in Montreal as to
what should be in a WG I-D for SSP.

Regards,
Stephen & Barry.

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

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Jun 2006 07:47:37 -0700

>off SSP-related discussions. (a) seems nicely in-hand.

Question (not a suggestion): why is 
draft-kucherawy-sender-auth-header not on that list? The base 
document talks about its functionality in a few places, and there 
seems to be an widespread but unstated belief that most DKIM 
verification will be done at incoming MTAs, not MUAs.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 07 Jun 2006 07:55:44 -0700

Paul Hoffman wrote:

> Question (not a suggestion): why is draft-kucherawy-sender-auth-header 
> not on that list? The base document talks about its functionality in a 
> few places, and there seems to be an widespread but unstated belief 
> that most DKIM verification will be done at incoming MTAs, not MUAs.

Well, it's not in our charter, but assuming that the -base discussion 
doesn't
take up the entire agenda it seems worthwhile socializing it in a 
pre-re-charter
kind of way. I'll note that Auth-res is pretty intertwinned with SSP as 
well.

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Wed, 07 Jun 2006 15:53:27 -0700

> achieving our charter goals related to SSP.
We do have draft-allman-dkim-ssp-01; is there any problem with using
that as a starting point?  Or do we need to lay some groundwork first,
such as a requirements document?

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 08 Jun 2006 09:33:31 +0100

Jim Fenton wrote:
> that as a starting point?  

None at all - its even mentioned as such in our charter.

 > Or do we need to lay some groundwork first,

Eh...I'd be somewhat reluctant to introduce yet another document. But
if someone wanted to write up an I-D documenting possible requirements
(and non-requirements) for Montreal (i.e. in the next week), that'd be
interesting. I wouldn't like such a beast to be on the critical path
though, if at all possible.

S.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 08 Jun 2006 08:16:56 -0400

> that as a starting point?

As Stephen says, it's in our charter as a starting point.  But we have 
to consider it *a* starting point, because we've already seen at least 
two more views on what a signing policy/practices/poodle should look 
like, and they differ enough that we need to review them as separate IDs 
first.  I certainly expect that allman-dkim-ssp will be one of those we 
review.

Barry

--
Barry Leiba, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Fri, 16 Jun 2006 17:39:54 -0400

> off SSP-related discussions. (a) seems nicely in-hand.

I suggest that we explicitly solicit some discussion in the meeting with both
Security and DNS experts.  We have made some assumptions about what is likely to
be acceptable to each of those communities, yet I suspect we do not have much
feedback yet about their limits.

(I suspect we are in quite good shape, with respect to the Security folks, but I
find myself worried about the DNS constituency.)

So, for example, the DNS purists could well take exception to the choice we have
made for an initial TXT record, with a new RR outside the critical path of -base.

Montreal could give us some valuable insight into the likely problems we will or
will not have in getting -base approved.

Alternatively, we could go through working group last call, IETF last call, and
IESG push-back.  For any interesting push-back, we are probably looking at
delays in the range of 6 months.  (That estimate is, of course, not merely
theoretical.)

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Jun 2006 14:58:43 -0700

On Jun 16, 2006, at 2:39 PM, Dave Crocker wrote:

>
> So, for example, the DNS purists could well take exception to the  
> choice we have made for an initial TXT record, with a new RR  
> outside the critical path of -base.

It would be good to have a binary DNS RR defined within the base  
draft.  Depending upon how this record is used and what it contains,  
base64 encoding might exceed the 512 byte message limit, as  
previously explained in detail.  The savings from a binary encoded  
key should be compared against the space normally remaining.  This  
remaining space is affected by the domain name of the signing domain,  
the size of the 'g=' parameter, and whether other parameters become  
commonly included.   Such an effort could also benefit from expert  
DNS review and advise.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 16 Jun 2006 23:43:14 +0100

> find myself worried about the DNS constituency.)

Our esteemed AD asked the pertinent question of a DNS directorate
representative in an email on June 4th. (Sorry not to cc the list
with details, but I'm not sure if the individual concerned has
accepted being the contact point yet.)

Haven't heard anything back so far. I'll try get a status update
before the meeting, and we can put it on the agenda, though I
suspect this'll be one of those solved-in-the-corridor type things.

(Dave's right that allergic reactions here could be a cause of delay,
so if any of you have ways of informing/helping/speeding-up the DNS
folks, feel free to give 'em a nudge...)

Regards,
Stephen.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 16 Jun 2006 15:49:44 -0700

At 2:58 PM -0700 6/16/06, Douglas Otis wrote:
>It would be good to have a binary DNS RR defined within the base draft.

Fully disagree. The current protocol (a TXT record that is only used 
in namespaces that are specific to the DKIM protocol) is sufficient.

>Depending upon how this record is used and what it contains, base64 
>encoding might exceed the 512 byte message limit, as previously 
>explained in detail.

... which few (if any) agreed with.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Jun 2006 16:08:11 -0700

On Jun 16, 2006, at 3:49 PM, Paul Hoffman wrote:

>> draft.
> Fully disagree. The current protocol (a TXT record that is only  
> used in namespaces that are specific to the DKIM protocol) is  
> sufficient.

If there were a namespace registry regarding these labels, there  
would be less concern.  It is ironic this names space is already  
being shared by a separate application called DomainKeys and there  
are already parameter conflicts.  : (

>> Depending upon how this record is used and what it contains,  
>> previously explained in detail.
>

The numbers were rather detailed.  Did you find an error in the  
assessment?  Other than believing 2048 bit keys will not be used,  
what would be the basis for disagreement?

-Doug