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!

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

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.