[06:42:28] --- dcrocker has joined
[08:42:39] --- dcrocker has left
[09:14:01] --- dcrocker has joined
[10:51:37] --- dcrocker has left
[11:05:48] --- dcrocker has joined
[11:08:36] --- mrichardson has left
[11:19:30] --- dcrocker has left: Replaced by new connection
[11:19:31] --- dcrocker has joined
[11:26:23] --- mrichardson has joined
[11:26:46] --- mrichardson has left
[11:28:52] --- mrichardson has joined
[11:39:08] --- dcrocker has left: Replaced by new connection
[12:02:02] --- LOGGING STARTED
[12:18:16] --- dcrocker has joined
[12:44:04] --- fenton has joined
[12:45:06] * fenton has changed the subject to: DKIM WG meeting begins at 1740 EDT
[12:45:48] --- fenton has left
[12:56:04] --- mrichardson has joined
[13:30:23] --- dcrocker has left: Replaced by new connection
[14:36:59] --- mrichardson has left
[14:37:15] --- mrichardson has joined
[14:39:10] --- Dennis Dayman has joined
[15:23:37] --- dcrocker has joined
[16:19:15] --- dcrocker has left: Replaced by new connection
[16:27:52] --- fenton has joined
[16:50:00] --- fenton has left: Replaced by new connection
[17:29:05] --- thomasm has joined
[17:34:00] --- dcrocker has joined
[17:34:15] --- Chris Newman has joined
[17:34:17] --- doug_trend@jabber.org has joined
[17:35:02] --- fenton has joined
[17:35:49] --- dcrocker has left
[17:39:03] --- sftcd has joined
[17:40:41] <fenton> Jim Fenton, jabbering today
[17:40:50] <fenton> Barry Leiba introducing meeting
[17:41:11] <fenton> In WG last call for -base specification, ending Friday the 21st.
[17:41:16] --- Jim has joined
[17:41:19] --- raj has joined
[17:41:34] <fenton> Eric Allman reviewing the -base specification
[17:42:12] <fenton> List of issues from the issue tracker. 34 slides, but some small
[17:42:50] <fenton> #1287: removing DKIM signature headers if you know you're going to break it. CLOSED as is
[17:42:58] <thomasm> are these the open issues?
[17:43:15] <sftcd> yep though some just being formally closed
[17:43:42] <fenton> #1288 defining "signing address" in intro Closed.
[17:44:06] --- geoff has joined
[17:44:26] --- asullivan has joined
[17:45:27] <fenton> #1289 Signature process clarification. Language changed in -03. Removal of b= signature only applies to the signature being signed/verified.
[17:46:13] <fenton> #1293. Tagging keys/sigs with "deprecated" flag. Concern about use of old algorithms.
[17:46:31] <thomasm> wasn't this closed before?
[17:47:23] <fenton> Doug Otis: Concern was more about possibility about other things being affected by DKIM services. Downgrade attack against DKIM services
[17:47:52] <fenton> Otis: Not bad enough to stop using, but bad enough that you want to avoid the downgrade attack.
[17:47:58] <sftcd> issue tracker list URL has details:
[17:48:00] <sftcd> 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=
[17:48:22] --- tlr has joined
[17:48:35] <fenton> Barry Leiba: ekr and Russ said in Dallas we don't need to worry about this
[17:49:24] <fenton> Barry: Agreement that this isn't a problem
[17:49:40] <fenton> Phill Hallam-Baker: This belongs in policy layer
[17:49:53] <fenton> Eric: #1294 i= parameter conflict closed
[17:50:27] --- dcrocker has joined
[17:50:32] <fenton> #1308 Security considerations for _domainkey subdomain. Raised by Doug Otis
[17:51:01] <thomasm> wasn't this resolved with the t=s flag?
[17:51:27] <fenton> Otis: Concern was about the allowance in the i= parameter to have a parent domain sign for it. If parent domain uses DKIM and has a key compromised, it can spill over into subdomain.
[17:51:41] <thomasm> oh, back to this problem that is a characteristic of DNS
[17:51:52] <fenton> Mitigated somewhat by subdomain flag, but that's under control of parent
[17:52:04] --- Melinda has joined
[17:52:06] <fenton> Might require new service agreement between parent and subdomain.
[17:52:46] <thomasm> this is an OOOLLLLDDDD requirement!
[17:52:52] <thomasm> it's inherent in DNS
[17:53:26] --- kdz has joined
[17:54:07] <fenton> Paul Hoffman: Higher level domain issue exists for every application that uses DNS.
[17:56:21] <fenton> Peter Koch: Thought issue was closed. Has nothing to do with the fact that there's delegation in a parent zone. Mail community has a slightly different definition from others. But parents' keys ability to be used by child domains is unprecedented.
[17:58:04] --- edmon has joined
[17:58:05] <fenton> Jim Fenton: Parent keys SHOULD have t=s flag unless child signing is desired.
[17:59:36] <fenton> PHB: Concern about key at _domainkey.foo.example.com signing for example.com. (ans: no, the opposite is the case: _domainkey.example.com keys can sign for foo.example.com).
[17:59:58] <fenton> PHB: New security consideration. He volunteers to write something.
[18:00:11] --- resnick has joined
[18:00:30] <fenton> Steve Bellovin: Question was about TXT vs. other types discussed at DNS directorate meeting.
[18:00:40] --- healthyao2000 has joined
[18:02:39] <sftcd> Steve read out the following I believe:
[18:02:41] <fenton> Consensus: Directorate is unhappy with TXT. Registry of _ domains desirable. Subtyping a Bad Idea. TXT overloading is like HTTP overloading. Wildcard problems; we say we aren't using them but they don't think that will stick
[18:02:42] <sftcd> 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.
[18:03:04] <thomasm> MIC: -base doesn't use wildcards at all; this *is* an issue with SSP, but not with -base
[18:03:17] <fenton> PHB: Can address wildcards with PTRs
[18:03:31] <sftcd> (Mike - we're getting to that...)
[18:03:56] <fenton> Hoffmann: This isn't for directing email, which is where wildcards are used.
[18:04:49] <fenton> Bellovin: Other records besides TXT will be in the zone.
[18:05:10] <fenton> Olafur: Document should say "do not use wildcards".
[18:05:42] <fenton> Olafur: What if something else wants to use TXT records in the same zone?
[18:05:43] --- pguenther has joined
[18:05:52] <fenton> Barry: We do want a registry
[18:06:05] <fenton> Olafur: New process for new types, it's really fast.
[18:07:19] <fenton> Otis: Binary structure for keys would be more efficient. Also with EAI local-part would be 8-bit values, so that would be longer too.
[18:08:17] <fenton> DCrocker: Feedback to educate vs. that there is likely to actually be a problem. Does directorate intend to assert discuss-level concerns? (Bellovin: No)
[18:09:15] --- resnick has left
[18:09:45] --- alexeymelnikov has joined
[18:09:50] <fenton> Crocker: Comparison with HTTP is interesting. This is like HTTP on a different port (with _ prefix)
[18:10:13] <fenton> Stephen: As a WG we're OK, then.
[18:10:33] <dcrocker> Folks -- FYI I just posted a note to the mailing list that offers some text for possible IANA registries that the -base spec will need to include.l
[18:10:55] <fenton> Eric: #1316 Multiple minor issues. Mostly already addressed
[18:12:14] <fenton> Otis: Multibyte characters could affect g=. How about encoding with base64?
[18:12:55] <fenton> (several): Current syntax supports UTF-8.
[18:13:15] <fenton> Tony Hansen: Begs the question of "what is plaintext" in -base?
[18:13:28] <fenton> Eric: That's right, need to look at that
[18:13:55] --- ogud has joined
[18:14:05] --- ogud is now known as Olafur
[18:15:11] <fenton> subissue 6: 1024 bit key not requred per list consensus.
[18:18:27] <fenton> subissue 17: key consistency between key servers/services
[18:19:57] --- asullivan has left: Logged out
[18:20:03] <fenton> DCrocker: re multiple key services: Some services that have been proposed have more functionality than DNS. One could have a signature that validates with DNS and with the new service, but the new service carries additional meaning.
[18:21:39] <fenton> PHB: You really want to say that the multiple answers must be "compatible"
[18:21:55] --- mrichardson has left
[18:22:03] <fenton> eric: The current [weasel] words were carefully chosen, but willing to accept suggestions.
[18:23:01] <tlr> Isn't that spelt "SHOULD"?
[18:23:14] <fenton> DCrocker: Success with one method should be the same as with the other
[18:23:28] <fenton> Russ: MUST under normal circumstances is weird...
[18:23:32] --- anabolism@jabber.org has joined
[18:25:10] <fenton> subissue 22: specifying non-existent headers.
[18:25:57] <fenton> Stephen: Can you sign something that appears twice and prevent a third? (eric: Yes, include the header-field name three times, the first two will match something and the third will match nothing).
[18:26:15] <fenton> eric: Will include a bit more text there
[18:26:44] --- tonyhansen has joined
[18:27:17] <fenton> Subissue 24:
[18:27:57] <fenton> DCrocker: saying that you MAY add a verification header is normative, this should be in an explanatory note.
[18:28:06] <fenton> Chairs: agree
[18:28:49] <fenton> Thomas Roessler: (missed comment, sorry)
[18:29:26] <tlr> In that informational note, make sure you say that IF the header used shows up in the list of non-existing headers that is signed, this addition will invalidate the original DKIM signature.
[18:29:31] --- dcrocker has left: Replaced by new connection
[18:29:35] --- dcrocker has joined
[18:29:36] --- Courtney has joined
[18:29:45] <dcrocker> 1316 multiple key language proposal: “All listed query mechanisms SHOULD return keys that produce the same verification results, during normal circumstances.”
[18:30:28] <fenton> Discussion of compliance of a verifier that only looks at one signature.
[18:30:37] --- Courtney has left
[18:30:55] <fenton> Pete Resnick: SHOULD means do it that way unless you have a good reason to do otherwise.
[18:31:11] <fenton> Otis: Concern about amplification attacks from multiple signatures.
[18:31:40] <fenton> SHOULD you verify an arbitrary number of signatures?
[18:32:35] <fenton> Tony Hansen: Concern about future extensions, e.g., RSA-SHA512. If they generate two signatures, and receiver doesn't verify all of them, they're likely to miss a valid signature.
[18:33:13] --- tlr has left
[18:33:28] <fenton> eric: there is text about verifying the signatures in order, and putting the signatures in the proper order.
[18:33:35] --- Thomas Roessler has joined
[18:33:43] <fenton> Otis: Top down or bottom up?
[18:33:48] <fenton> eric: Top down.
[18:33:54] <dcrocker> inside out
[18:34:08] <dcrocker> (oops. this isn't the bad-attitude list. sorry.)
[18:34:30] --- Jim has left
[18:34:30] <fenton> eric: Verifier doesn't have to verify any signatures. We can't specify what the verifier does
[18:34:39] <fenton> Barry: 5 min warning.
[18:35:53] <fenton> eric: pls break any remaining issues out separately.
[18:36:51] <fenton> #1317: abstract wording
[18:37:23] <fenton> Jim Fenton: "repudiation" doesn't appear anywhere else but in the abstract. Proof only in a different context.
[18:40:35] <fenton> #1317 subissue 22: remove vs. revoke key: eric is neutral on wording.
[18:40:59] <fenton> DCrocker: Keeping the DNS record is extra overhead. Why?
[18:41:15] <fenton> eric: Think it's a negative caching issue.
[18:41:35] <fenton> DCrocker: Why is it useful to know the record used to exist?
[18:42:14] <thomasm> I would think that negative cache time should be fine though
[18:42:25] <fenton> Barry: If for some reason you're verifying signatures after expiration, the cached copy is useful.
[18:43:06] <fenton> Otis: Distinction between expired and revoked key. Revoked is stronger.
[18:43:23] <fenton> (several): Revoked is no stronger than expired.
[18:43:35] <thomasm> +1 crocker
[18:43:56] <fenton> DCrocker: Operators will not appreciate remembering to remove old records a year later...
[18:44:13] <fenton> Philip Guenther: Remember that there is negative caching in DNS.
[18:44:35] <fenton> Otis: If there is a semantic difference, this could provide it.
[18:44:44] <fenton> Barry: Agree, but the spec isn't written that way.
[18:44:45] --- kdz has left
[18:44:54] <dcrocker> jim - small correction: Operators will not appreciate HAVING TO remember to remove old records a year later...
[18:45:03] --- Olafur has left
[18:45:18] <fenton> Barry: We meet again tomorrow afternoon. See you then.
[18:45:29] --- tonyhansen has left
[18:45:31] --- Chris Newman has left
[18:45:32] <fenton> DCrocker: thx
[18:45:41] --- Thomas Roessler has left
[18:45:42] <sftcd> tomorrow we meet at 1300 in 518ab
[18:45:44] --- dcrocker has left
[18:46:10] --- fenton has left
[18:46:20] --- fenton has joined
[18:46:47] * fenton has changed the subject to: DKIM WG adjourned until 12 July at 1300 EDT
[18:46:53] --- raj has left
[18:46:57] --- fenton has left
[18:47:25] --- Melinda has left
[18:47:40] --- Dennis Dayman has left
[18:48:38] --- mrichardson has joined
[18:50:21] --- sftcd has left: Computer went to sleep
[18:52:42] --- doug_trend@jabber.org has left: Logged out
[18:53:35] --- alexeymelnikov has left
[18:53:49] --- healthyao2000 has left
[19:00:54] --- dcrocker has joined
[19:02:45] --- edmon has left
[19:16:51] --- thomasm has left
[19:17:24] --- dcrocker has left
[19:20:37] --- geoff has left
[19:26:14] --- anabolism@jabber.org has left
[19:35:39] --- pguenther has left
[19:44:25] --- edmon has joined
[19:48:46] --- edmon has left
[20:48:51] --- kdz has joined
[20:50:32] --- kdz has left
[22:14:54] --- dcrocker has joined
[23:44:07] --- mrichardson has left