Subject: [ietf-dkim] Final Montreal minutes...

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Aug 2006 09:33:11 +0100

Folks,

The attached are the final minutes from Montreal for the
record. There're only trivial changes from the earlier
draft minutes.

Cheers,
S.

IETF-66 FINAL DKIM Meeting Notes (-01)

Charter: http://www.ietf.org/html.charters/dkim-charter.html

Chairs: Barry Leiba, Stephen Farrell

We met twice. Thanks to the jabber scribes!

Tuesday: 67 attendees, jabber: Jim Fenton, http://www.ietf.org/meetings/ietf-logs/dkim/2006-07-11.html

Wednesday: 63 attendees, jabber: Pete Resnick, http://www.ietf.org/meetings/ietf-logs/dkim/2006-07-12.html

Audio logs: http://videolab.uoregon.edu/events/ietf/

Agenda, slides etc: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66
search/scroll down to "DKIM"

Minutes: Stephen Farrell

Highlights

The WG chairs had asked for help from the DNS directorate about whether
or not DKIM needs to define a new RR or is ok to use the current approach
of a TXT record for the public key. The feedback is that although there's
some unhappiness with the TXT approach, in this case it appears to work.
So the WG approach for base will be to include the TXT record definition
and not to define a new RR for public keys. (More detail below.)

The base spec is in WGLC, ending on Friday 21st July. Almost all issues
are closed or should hopefully be closed in a -04 draft to be posted this
week. The main issue remaining is whether or not the "relaxed" body
canonicalization should remain in the base document or not, where we
don't yet have clear consensus. We plan to try determine that on the
list.

We started discussion of SSP which is intended to allow signers to
announce their DKIM related practices. A couple of drafts exist that
outline proposals. Discussion here is just at the very start and there
were some requests that we try to establish concrete requirements before
going futher.

We now have a draft of the DKIM overview document (intended to be
informational) which is also up for discussion.

Tuesday

Eric Allman - base issues

Eric went through all of the issues with the base spec from the
tracker.

base spec: http://www.ietf.org/internet-drafts/draft-ietf-dkim-base-03.txt

tracker:

1287: Leave as is, CLOSED

1288: CLOSED

1289: CLOSED

1293: Doug - its about downgrade attacks. Decided already. CLOSED

1294: CLOSED

1308: Doug - DNS security considerations needed. Paul Hoffmann, DKIM is
the same as anyone else. Peter Koch, don't use DNS to deduce organisational
relationship from DNS structure. Paul thinks he and Peter agree in fact. Jim
Fenton we should add language RECOMENDING use of "t=s" to make such problems
less likely. PHB volunteers to write text.

Bellovin on the DNS directorate issue: question about TXT vs other RR for
_domainkey. Spent 45 minutes at DNS directorate. Steve not chair, but
consensus. Quoting:

"The DNS directorate is unhappy with using TXT records this way. Some of
the reasoning is spelled out in draft-iab-dns-choices-03.txt. At the least, a
registry of _ names is needed, with provision for subtyping, but subtyping
RRs has long been known to be bad . In general, TXT overloading can be
likened to using HTTP as the universal transport protocol; see RFC 3205 for
why that's a bad idea.

A more specific problem for this situation is the issue of wildcards.
Briefly, you can't have a wildcard _domainkeys record; given that email is
the major place where wildcards are used, this is a serious issue."

DNSSEC signing records at least may be found below _domainkeys and other
RRs deliberately or by accident.

Olafur: If doc says "do not use wildcards" that'd be good. Proposes an
experiment to acquire a new type if the WG want to try that (a fast process
apparently).

Doug - eai may expand record as well as longer keys. Suggests that
alternative to TXT might be good for that.

Crocker: Question to Bellovin: Would DNS directorate assert a DISCUSS.
Bellovin: No-one said DISCUSS, but unhappiness. On the plus side, its a
special record and we don't have to contend with other TXT records.

Way forward: WG will only specify a TXT for keys for now.

Back to issues:

1316: multiple issues in one. a couple of minor things before we can close
this.

#1 multibyte. EAI etc. Can't predict every future protocol. Doug - UTF8
would affect g= in key - we could b64 that in the key record. Eric: No
problem so long as they stick with UTF8. Tony Hansen: does base- define plain
text. Eric: it will (ACTION)

#2, == 1323

#3, max length. none.

#4 == #1

#5 answered (no)

#6 nope & ok

#7 looking for reference

#8 fixed, API stuff on list

#9 == #1

#10 yes

#11 answer=unchanged

#12 relaxed -> New01

#13 l=0;bh= done on list

#14, new text from Jim

#15, no

#16, done

#17, new wording fine, Dave Crocker: what about additional services.
Delete substantially? Dave C offered words to put in jabber.

#18 = 1325

#19, done

#20 = 1322

#21 done

#22, Eric ACTION to add a bit more guideance on trace headers when you
only want 2 and no more

#23, done

#24, auth-results addition issue generally make this stuff be
informative

#25, yes SHOULD is enough? Doug - no limit on max sigs? Tony Hansen: alg
transition & if not all sigs checked cause not all sigs checked. Answer:
verifiers ordering is up to verifier.

#26, done

#27, no looping

#28, reject if key too short? if it wants.

1317:

#1, proof & non-repudiation: remove offensive words ACTION

#2, why not add it? ACTION: add that

#3, TTP issue - +"additional" is ok.

#4, done

#4': done

#5 -> 1322

#6 done

#7 resolved

#8-#11 all done or ok

#12-#16 all done

#17-#19 all done

#20, ok because of downgrade

#21 ok

#22, remove record or else remove key from record? remove record is normal
behaviour

#23, #24: ok

Wednesday

#25 ok

#26-#29: ok

#30-#34: ok, language to be offered. Dave C says he'll look back at it

1318: CLOSED

1319: rewritten now

1320: IANA considerations, working issue with text from Dave C.

1321: #1, #2 fixed, #3: wildcards in hash algs, CLOSED if no support

1322: key record format, rewritten

1323: dots, selectors, agreed on list CLOSED

1325: proposal one "*" anywhere in the string CLOSED

New01: drop relaxed? Tony : who's not done relaxed? no-one. Some have.
Paul: take it out to a separate spec. Tony H. reminded of content-transfer
encodings in MIME, no additional ones in 15 years. So keep relaxed in base.
PHB: xml case ended up with push-back, so take it out unless someone really
needs it in (Mike T. is saying that.) Jim F (as himself): EOL stuff probably
affects simple as well as relaxed. Schaad: multipart can be problematic too,
you may have to force. Barry: maybe roll into simple. Doug: could make it
stateful, depending on different encodings. Take to list, no clear
consensus.

New02: allow wildcardings in h=. Jim F: could be in a config. PHB:
reminiscent of criticality, doesn't like. Dave: heard word MUA, so don't do
it. Eric: wildcard bring back order issues. No support in the room

Jabber

Stephen reported on the jabber meetings tha the WG had had. Russ asked the
chairs to send a note to wgchairs (ACTION: Barry). Paul H: agendas at least a
day before please. Jon Callas and Mark Delaney have said that they dislike
this use of jabber (at least the timing is difficult for them).

Sender Signing Policy etc.

Fenton

Dave C: any SSP lookup on a signed message is a mistake. Explained. He
gets it.

Paul H: doesn't like 3-party signature issue affecting "goodness"

Dave C: if it needs lots of lookups - guaranteed to fail.

Mike Thomas (jabber): not a problem in practice

PHB: lots of DNS lookups already, better if its designed well

Peter Koch: doesn't see an operation issue, doesn't like tree-climbing,
consider accumulated latency due to failed queries

Paul H: negative caching is your friend only if you have a v. large cache,
not all are, if LRU cache then SSP may push out A records due to its
lookups.

Hallam-Baker

If current ssp doesn't work start from a generic policy into which DKIM
can fit.

Otis

Presented his slides on another PTR based approach.

Open Mike wrt SSP

Olaf?: PTR generally used for looking for a further lookup, doesn't like
Doug's use of PTR (not sure about PHB's but maybe ok modulo implementations
that only do reverse lookup) proposes using a new RR.

PHB: in this case, if PTR has issues then he could be convinced that a new
RR should be used (or something else not frequently used). Disagrees that
he's usurping.

Peter Koch: rfc1101 a problem, overloading PTR is as bad as overloading
TXT

Dave C: back to 1st prinicples please, been waiting a while for this. We
usually have a framework when we develop protocols, this stuff is fuzzy.
Wants requirements clarified ahead of time (I think).

Otis: thinks SSP won't provide as much as people will think it will.

Paul H: how do we design this question? we don't expect universal adoption
of SSP for all DKIMs. Want to answer a question: Is this still useful if 20%
of DKIM validators don't use SSP?

Barry: how broad should this be? Doug: not that broad.

Dave C: larger scope sounds like boiling the policy ocean. Scope may be
premature too if we don't know what entities we're designing for.

Michael Richardson: PHB's choice 2, 1999 genarea had a "policy" wg,
results not used at all. Is that what PHB meant? PHB: look @ X.509 and then
SAML, there are a bunch of components doing the same thing but not unified,
and infrastructure designed to be much more general. Point being you can
design for specific purpose but also end up with a general solution.

Drafts encouraged.

Eric allman: should I freshen draft-allman-ssp? Answer: Sure, if you like
more work.

Overview

Tony H: presented his slides on the overview document.

Paul H: does this address future things? Barry - sort of, its the last WG
document.

PHB: would be ok with something.

Mike T: could this be a BCP? Not really.

Dave C: When to push this out and what are the boundaries for the 1st
cut?

Paul Hoffman

Introduces DAC.

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