[02:12:16] --- mrichardson has left
[06:19:42] --- pascal_Hennequin has joined
[06:21:13] --- pascal_Hennequin has left
[09:06:51] --- mrichardson has joined
[09:06:57] --- mrichardson has left
[09:07:07] --- mrichardson has joined
[10:07:52] --- jc_lee has joined
[10:07:59] --- jc_lee has left
[10:14:00] --- LOGGING STARTED
[10:16:47] --- mrichardson has joined
[10:19:28] --- mrichardson has left: Logged out
[10:19:36] --- mrichardson has joined
[10:43:34] --- dcrocker has joined
[10:45:03] --- jas has joined
[10:50:16] --- mike thomas has joined
[10:59:11] --- mike thomas has left
[11:00:45] --- thomasm has joined
[11:51:29] --- pguenther has joined
[11:54:05] --- dcrocker has left
[12:07:02] --- ggm has joined
[12:59:30] --- LOGGING STARTED
[12:59:40] --- jas has joined
[13:03:30] --- LOGGING STARTED
[13:04:40] --- jas has joined
[13:11:38] --- dcrocker has joined
[13:26:23] --- jlcjohn has joined
[13:30:02] --- dcrocker has left
[13:53:03] --- Eliot has joined
[13:53:06] --- doug_trendmicro@jabber.org has joined
[13:53:38] --- doug_trendmicro@jabber.org has left
[13:54:27] --- Doug_O has joined
[13:54:43] --- marcos.sanz has joined
[13:55:59] --- marcos.sanz has left
[13:56:11] --- Eliot has left: Logged out
[13:56:20] --- fenton has joined
[13:56:44] --- marcos.sanz has joined
[13:57:46] --- eric has joined
[13:58:46] --- Eliot has joined
[13:58:48] --- joncallas has joined
[13:58:52] --- tonyhansen has joined
[13:59:21] <Eliot> good afternoon/evening everyone and welcome to the IETF 65 DKIM working group jabber chat.
[13:59:53] <Eliot> we are having some network flakiness, and so jabber connectivity will be imperfect
[14:00:14] <Eliot> if you have a question for the microphone please prefix your comment with MICROPHONE:
[14:00:42] --- Barry Leiba has joined
[14:01:06] <Eliot> stephen has brought the meeting to order
[14:01:13] <Eliot> document status is now on the screen
[14:01:21] --- nov has joined
[14:01:28] <Eliot> we want to close issues by the end of the meeting
[14:01:40] <Eliot> Stephen: seems to be really good consensus on threats
[14:01:42] --- arvel has joined
[14:01:50] --- Hollenbeck has joined
[14:01:56] --- resnick has joined
[14:02:10] --- Eliot has left: Logged out
[14:02:40] --- Eliot.Lear has joined
[14:02:44] --- alexeymelnikov has joined
[14:02:49] <Eliot.Lear> this is eliot again
[14:03:00] <Eliot.Lear> (using different identity)
[14:03:10] <Eliot.Lear> we have two meeting slots
[14:03:15] --- pawal has joined
[14:03:21] <Eliot.Lear> other meeting is at 1510 on wednesday (CSD)
[14:03:23] <Eliot.Lear> (CST)
[14:03:44] <Eliot.Lear> today, hope is to resolve threats issues and as many base issues as we can.
[14:03:51] <Eliot.Lear> wed: begin discussing SSP
[14:03:59] --- yone has joined
[14:04:27] --- jimsch1 has joined
[14:04:55] <Eliot.Lear> agenda bashing
[14:05:07] <Eliot.Lear> threats issues is next (30 minutes)
[14:05:10] --- eric has left
[14:05:12] <Eliot.Lear> base doc - 90 minutes
[14:05:24] --- lisaDusseault@jabber.psg.com has joined
[14:05:41] <Eliot.Lear> jim fenton is now comming to the microphone
[14:05:43] --- harald has joined
[14:06:07] <Eliot.Lear> draft-ietf-dkim-threats-01
[14:06:11] --- joncallas has left
[14:06:33] <Eliot.Lear> doc has morphed to "what are the specific threats to dkim"
[14:06:40] --- NFreed@jabber.org has joined
[14:06:49] <Eliot.Lear> and threats to infrastructure due to dkim
[14:06:54] <Eliot.Lear> this is not a tutorial.
[14:06:58] <Eliot.Lear> draft is in last call
[14:07:02] --- hardaker has joined
[14:07:08] --- thomasm has joined
[14:07:50] <Eliot.Lear> added descriptions of a few new threats, one threat being the possibility that a higher level domain of a registrant within a given TLD might decide to publish keys
[14:08:07] <Eliot.Lear> falsification on replies to sender signing practices
[14:08:34] <Eliot.Lear> possible threats to amplification attacks against DNS
[14:09:01] <Eliot.Lear> because requests are smaller than replies, there is an attack
[14:09:12] --- joncallas has joined
[14:09:39] --- raeburn@jis.mit.edu has joined
[14:09:46] --- raeburn@jis.mit.edu has left
[14:09:57] --- raeburn has joined
[14:10:14] <Eliot.Lear> some of the tone has been mixed (between normative and non-normative). jim is fixing the tone to be non-normative
[14:10:26] --- eludom has joined
[14:10:29] <Eliot.Lear> description of reply variant of chosen msessage replay
[14:10:52] <Eliot.Lear> bounce messages are the vector for attackers these days
[14:11:00] <Eliot.Lear> lots of minor editorial gnits
[14:11:09] <Eliot.Lear> open issues can be found on rt.psg.com
[14:11:23] <Eliot.Lear> 1171 clarification of dkim mechanism in introduction
[14:11:29] <Eliot.Lear> (these are open issues)
[14:11:36] <Eliot.Lear> excluding ekr's from yesterday
[14:12:03] --- nsb has joined
[14:12:06] <Eliot.Lear> it was felt that the description of the mechanism was not clear. we are trying to keep description in threats consistent with base.
[14:12:19] <Eliot.Lear> if we make a change here we need to consider the change for the base document
[14:12:40] <Eliot.Lear> 1172 impact of signed message replay. there are impact ratings and these are somewhat arbitrarily chosen.
[14:13:03] <Eliot.Lear> 1222 ABNF: sender = originator / operator - is this a threats issue?
[14:13:21] --- joncallas has left: Replaced by new connection
[14:13:36] <Eliot.Lear> are there any questions or comments? if you have a question for the microphone please prefix your comment with MICROPHONE:
[14:13:45] <Eliot.Lear> paul hoffman at the mike
[14:14:03] --- ogud has joined
[14:14:11] --- dcrocker has joined
[14:14:40] <Eliot.Lear> collision attacks? when messages can and cannot get through with filters?
[14:14:52] --- marz has joined
[14:15:10] --- joncallas has joined
[14:15:13] <Eliot.Lear> stephen: proposal is for paul to provide text
[14:15:34] --- kivinen has joined
[14:15:35] <Eliot.Lear> paul will provide an addition to text. this will be a new issue.
[14:16:06] <Eliot.Lear> this is a hash collision if the same author can do both of the messages and one message wouldn't normally get through
[14:16:16] <Eliot.Lear> is this really a threat?
[14:17:31] <Eliot.Lear> jim is not following the tie in of the non-delivery of some messages to the attack
[14:18:00] <Eliot.Lear> for a collision attack to be at all valid, he has to be able to take a bad message and create a collision with a good message. (?)
[14:19:04] <Eliot.Lear> if there is a semantic filter based on a bad message, then repurposing a bad message as a good message after a collision would be the attack.
[14:19:05] <thomasm> somebody capable of doing such an attack could surely find better employment, no?
[14:19:17] --- handle has joined
[14:19:18] <Eliot.Lear> reminder: if you have a question for the microphone please prefix your comment with MICROPHONE:
[14:19:31] <Eliot.Lear> jon callas
[14:19:52] <Eliot.Lear> how much of this presupposes 2nd preimage attacks?
[14:19:56] <Eliot.Lear> audience: none of it
[14:20:35] <Eliot.Lear> stephen: clarify side channel attack.
[14:20:46] <Eliot.Lear> ekr: i'll provide text.
[14:20:52] <Eliot.Lear> this will be a new issue
[14:21:06] <Eliot.Lear> jim fenton:
[14:21:42] <Eliot.Lear> 1171: we're happy with the wording that's there. this has to do with taking responsibility for a message versus being held accountable.
[14:22:02] <Eliot.Lear> barry lieba: this is a weak statement. we're not trying to enable legal actions
[14:22:03] --- jis has joined
[14:22:07] <Eliot.Lear> doug otis:
[14:22:26] <Eliot.Lear> one of the connotations of a responsibility is a direct action
[14:22:27] --- pk has joined
[14:23:09] --- joncallas has left: Replaced by new connection
[14:23:11] <Eliot.Lear> in terms of signing something there is no direct action. you didn't create the message. the word accountability infers that you'll pay the price for signing messages that were bad
[14:23:31] <Eliot.Lear> in terms of the message, the point is to know who you can come to to get it to stop
[14:23:32] --- joncallas has joined
[14:23:40] <Eliot.Lear> stephen: is this worth holding up the doc?
[14:23:49] <Eliot.Lear> doug: this becomes a bigger issue later on
[14:23:54] --- robsiemb has joined
[14:24:13] <Eliot.Lear> barry: we've previously said, "claim responsibility for inserting this message into the mail stream"
[14:24:44] <Eliot.Lear> stephen: i don't care and would be persuaded by the editors
[14:24:50] <Eliot.Lear> stephen: proposed reject
[14:25:33] <resnick> Personally, I prefer Barry's above formulation.
[14:25:46] <Eliot.Lear> dave crocker: nitpicking on this issue might be warranted. the thing to do is to listen to others outside the immediate group [who don't have the unwritten context] to see how they interpret it.
[14:26:06] <Eliot.Lear> stephen: would you take an action to try and do this by friday?
[14:26:08] --- newcat has joined
[14:26:14] <Eliot.Lear> dave: [not really]
[14:26:58] <resnick> Eliot says at the mic:
[14:27:06] <joncallas> (Elliot lear says at the mic....)
[14:27:34] <joncallas> We're making statements about the past that might not be able to be verified for very long in the past.
[14:27:35] <Eliot.Lear> philip hallam baker:
[14:28:04] <Eliot.Lear> dkim 1.0 leaves off all the things you want for accountability, like accreditation and consequences
[14:28:37] <Eliot.Lear> jim fenton:
[14:28:53] <Eliot.Lear> accountability involves finding the person that's responsible.
[14:29:06] <Eliot.Lear> [don't think we can do that]
[14:29:31] <Eliot.Lear> stephen: let's push this into the overview document
[14:29:36] <Eliot.Lear> barry: [agrees]
[14:29:59] <Eliot.Lear> stephen: phil will take an action to write text for the overview document
[14:30:05] <Eliot.Lear> stephen: proposed reject 1171
[14:30:09] <Eliot.Lear> 1172
[14:30:51] <Eliot.Lear> there are two replay attacks. signed message replay you take an arbitrary message that's signed and spray it out to a lot of places it wasn't intended to go. main motivation is to degrade sending domain's reputation
[14:30:57] --- marcos.sanz has left
[14:31:03] --- marcos.sanz has joined
[14:31:16] --- kmurchison has joined
[14:31:18] <Eliot.Lear> chosen message replay- gets at least one message signed by a domain. and then spray it all over the world
[14:31:40] <Eliot.Lear> barry: they're both listed as low impact
[14:31:46] <Eliot.Lear> doug otis:
[14:32:11] <Eliot.Lear> low impact implies this doesn't impact the entire domain.
[14:33:17] <Eliot.Lear> this would impact the domain, and therefore the impact is high
[14:33:41] <Eliot.Lear> one mitigation would be varying levels of trust with keys
[14:33:58] <Eliot.Lear> jim fenton:
[14:35:18] <Eliot.Lear> what the question comes down to, in terms of impact we're looking at the ability to spoof sign messages on a per user or per domain basis, or whether the impact would be domain wide. i chose to reflect impact ratings on whether an attack allows an attacker to sign a specific message.
[14:35:34] --- resnick has left
[14:35:38] <Eliot.Lear> doug: this attack is on the receiving side, not the sender side
[14:36:14] --- resnick has joined
[14:36:42] <Eliot.Lear> paul hoffman: this sounds like base as opposed to threats is because there are too many requirements on the receiver without saying why. we've handed the receiver enough rope to ruin reputations, but this is not specific to dkim
[14:37:16] <Eliot.Lear> paul: happy with low impact
[14:37:53] <Eliot.Lear> john levine: one of things we're planning to look at is BCPs. worry about the technical concrete part as opposed to the stupid stuff, and we'll handle that for you
[14:37:55] <Eliot.Lear> (laughs)
[14:38:08] <Eliot.Lear> consensus is low impact
[14:38:12] <Eliot.Lear> proposed reject
[14:38:16] <Eliot.Lear> 1222
[14:38:25] <Eliot.Lear> ABNF sender/origniator/operator
[14:38:31] <Eliot.Lear> jim fenton
[14:38:58] <Eliot.Lear> didn't see a lot of uses of "S"ender. are there particular places where the terminology needs to be fixed
[14:39:26] <Eliot.Lear> dave crocker: the use of the word is so imprecise we shouldn't use the word at all ever, and use words that have more precise meaning
[14:39:58] <Eliot.Lear> dave crocker to go through document and check the use of the word sender.
[14:40:15] <Eliot.Lear> dave will propose concrete changes based on that search
[14:40:25] --- ve6bbm has joined
[14:40:33] <Eliot.Lear> Eric Allman now presenting
[14:40:53] <Eliot.Lear> DKIM Base Spec open issues
[14:41:36] <Eliot.Lear> 1183
[14:41:43] <Eliot.Lear> (again, issues are at rt.psg.com)
[14:41:55] <Eliot.Lear> should we have the r=tag in either signature or key record
[14:42:33] <Eliot.Lear> if r= is a localpart, then complain to the signer
[14:42:48] <Eliot.Lear> it's about reporting not complaining
[14:42:53] <Eliot.Lear> murry k. from sendmail:
[14:43:11] <Eliot.Lear> this was for interoperability testing, where should i send back analytical data?
[14:43:23] <Eliot.Lear> useful only for debugigng
[14:43:35] <Eliot.Lear> paul hoffman: there is no r= in the base spec
[14:44:02] --- lisaDusseault@jabber.psg.com has left: Logged out
[14:44:07] <Eliot.Lear> Eric: punt this issue to the SSP spec
[14:45:08] <Eliot.Lear> doug otis: this DOES belong in the base spec, but hidden by the selector
[14:46:29] <Eliot.Lear> you want a reporting vector based on the signer
[14:47:19] <Eliot.Lear> Philip Hallam Baker: any attempt to push things into the key selector is doomed to failure
[14:47:43] <Eliot.Lear> it's logically part of a policy, which is part of SSP
[14:47:59] <Eliot.Lear> the reporting mechanism needs to be secure from DOS attacks
[14:48:01] <Eliot.Lear> dave crocker:
[14:48:15] <Eliot.Lear> what's the base what's more than the base.
[14:48:17] --- marcos.sanz has left
[14:48:18] <ve6bbm> Dave: please speak up into the mic ...
[14:48:19] --- marcos.sanz has joined
[14:48:20] <Eliot.Lear> i want a small base
[14:48:49] <ve6bbm> I know, scary ... :-)
[14:48:50] <Eliot.Lear> jabber: is that better?
[14:48:52] <ve6bbm> no he doesnt
[14:49:38] <Eliot.Lear> 2nd issue is should we have an r= in base spec or somewhere where the base spec can get to it.
[14:49:51] <Eliot.Lear> dave said place it somewhere other than the base spec
[14:49:55] <Eliot.Lear> (barry's summary)
[14:50:06] --- stephenfarr has joined
[14:50:15] <Eliot.Lear> murray: if you find a tag and you ignore it, then who cares?
[14:50:20] <Eliot.Lear> (groans)
[14:50:23] <Eliot.Lear> (X-r?)
[14:50:40] <Eliot.Lear> Barry: either we don't need it all, we need it now, or we need it in the future
[14:51:02] <Eliot.Lear> Doug Otis: for SSP, the basis is coming from the email address. it has nothing to do with who's doing the siging
[14:51:39] <Eliot.Lear> barry: the implication is that there is a distinction between no signature and a broken one
[14:52:13] --- nsb has left: Logged out
[14:52:15] <Eliot.Lear> DO: we have a big problem with people getting DSNs they have nothing to do with.
[14:52:17] --- nsb has joined
[14:52:44] <Eliot.Lear> jim fenton: why do we need an r= instead of "postmaster"
[14:52:54] <Eliot.Lear> {line closed}
[14:53:16] <Eliot.Lear> murray: do other protocols do this sort of stuff?
[14:53:30] --- marcos.sanz has left
[14:53:34] --- nsb has left
[14:53:35] --- marcos.sanz has joined
[14:54:10] <Eliot.Lear> john callas: i think there is a reason to have this for SSP, but in general you're not going to have it there, but you want messages discarded when they're not signed, in general, just discard so that errors cause nothing.
[14:54:59] <Eliot.Lear> phb: exception: banks under attack by phishing. however, what i really want is report via a different channel - (perhaps a) web service.
[14:55:44] --- randy g has joined
[14:55:50] <Eliot.Lear> stephen; doug otis will argue for r= in the mail address, phil hoffman will argue against
[14:56:07] <Eliot.Lear> eric: this was supposed to be noncontentious
[14:56:10] <Eliot.Lear> 1184
[14:56:26] <Eliot.Lear> multiple crypto algorithms
[14:57:35] <Eliot.Lear> paul hoffman: wearing VPN Consortium hat... there's been a year long effort to quantify and state exactly how protocols use hashes, so that when hashes degrade we have a way to move from one to another. ekr and smb have written a document on the need to go from one to another
[14:57:47] --- nsb has joined
[14:57:57] --- dcrocker has left
[14:58:16] <Eliot.Lear> transition plan has to allow for some messages for some period of time to be signed by old and new
[14:58:44] <Eliot.Lear> do you want the receiver to be able to tell the sender that it won't trust [weak] signatures?
[14:59:00] <Eliot.Lear> stephen: that's what the proposed resolution says
[14:59:36] <Eliot.Lear> EKR: nothing wrong with that.
[15:00:05] <Eliot.Lear> EKR: not building an email repudation system, don't care either way.
[15:00:54] <Eliot.Lear> doug otis: there is a need to know which is the stronger and which is the weaker, and how many signatures to discard, as there will be hundreds of signatures.
[15:01:29] <Eliot.Lear> Barry/Stephen: there is a broader multiple signature issue and this needs to fit that.
[15:02:24] <Eliot.Lear> russ housley: my thinking is that you need the ability to support more than one signature. it's totally up to the recipient as [what to do next]. ietf could provide guidance.
[15:02:39] <Eliot.Lear> jim fenton: the key record is the right place to specify this.
[15:02:50] <Eliot.Lear> stephen: that's a separate issue
[15:03:07] <Eliot.Lear> ekr: it creates one more way for signers to screw it up. but either is fine.
[15:03:08] --- raeburn has left
[15:03:36] --- ve6bbm has left
[15:03:55] <Eliot.Lear> 1184: ACCEPT: discussion on how to choose signature. mark delany to provide text
[15:04:16] <Eliot.Lear> 1185 SHA1 versus SHA256
[15:05:10] <thomasm> did other people's audio die?
[15:05:13] <Eliot.Lear> Ned Freed: MUST have the ability to generate both SHA1 and SHA256
[15:05:40] --- nsb has left: Computer went to sleep
[15:06:11] <Eliot.Lear> phb: simplest: if you're going to "MUST" either, then make MUST for SHA256.
[15:06:46] --- ddennis has joined
[15:06:49] <Eliot.Lear> Ned Freed: i can live with slightly less restrictive than this.
[15:07:05] <Eliot.Lear> ACTION ITEM: ACCEPT modulo wording
[15:07:38] --- ddennis is now known as Dennis Dayman
[15:07:55] --- eludom is now known as George Jones
[15:08:28] <Eliot.Lear> 1193 hash the body and then hash the header. have separate hash function for header and body. the arguments are that you can figure out which is broken, and there may be some cost savings on only having to recomputing header on mass mailing.
[15:08:36] --- dcrocker has joined
[15:08:56] <Eliot.Lear> paul hoffman: fine with the way you suggested. don't have two ways.
[15:09:38] <Eliot.Lear> dave crocker: i like it. may be more useful for more than just dkim
[15:09:49] --- newcat has left
[15:09:50] <Eliot.Lear> ekr: name of header: Content-MD5 ;-)
[15:10:02] <Eliot.Lear> ekr: same hash algorithm, both cases
[15:11:05] <Eliot.Lear> ned freed: there's a certain slippery slope. it's been proposed that we have a hash methodology for individual MIME parts. this could allow for precomputing messages in a store. don't want to go there now, but we could go here in the future.
[15:11:23] <Eliot.Lear> barry: is there any reason we should not do this?
[15:11:42] --- marcos.sanz has left
[15:11:45] --- marcos.sanz has joined
[15:12:01] --- lyndon has joined
[15:12:13] <Eliot.Lear> jon callas: i don't mind if we change. on other related issues, you can build upon dkim by building your own headers and signing them.
[15:13:08] <Eliot.Lear> dkim is intentionally very flexible in what you can do. so [this is a specific case of that]
[15:13:30] --- joncallas has left: Replaced by new connection
[15:13:38] <Eliot.Lear> mark delany: does this open up the issue of multiple body hashes?
[15:13:53] <Eliot.Lear> tony hansen: how would l= play into this?
[15:14:08] <Eliot.Lear> paul hoffman: move it to the signature hash header
[15:14:29] <NFreed@jabber.org> This also helps debugging in some cases.
[15:15:05] <Eliot.Lear> phb: if you just checked the signature you can reuse a valid message hash.
[15:15:10] --- harald has left
[15:15:16] --- harald has joined
[15:15:25] <Eliot.Lear> tony: and then there are the other algorithms...
[15:15:40] <Eliot.Lear> Barry: seems we want to do this. and we want this to be a tag in the header.
[15:15:51] <Eliot.Lear> ACTION: ACCEPTED, Eric to provide wording
[15:16:14] <thomasm> mic: I'd really like to see the proposal for this first
[15:16:19] <Eliot.Lear> 1194
[15:16:42] <thomasm> especially since I have no audio :(
[15:16:44] <tonyhansen> does this mean we also need v=dkimv2? (because of the existing implementations that are all compatible with allman-base-01)
[15:16:47] <Eliot.Lear> ok
[15:17:25] <thomasm> ????? we just agreed to a backward incompatible change without list discussion???
[15:17:28] --- Eliot.Lear has left
[15:17:59] --- Eliot.Lear has joined
[15:17:59] <Eliot.Lear> ok... back
[15:18:12] <fenton> thomasm: Presumably the tag with the body hash would be a clue that it's signed in this new way.
[15:18:29] <Eliot.Lear> 1195
[15:18:48] <thomasm> a header hash is a *lot* easier to do
[15:18:50] <Eliot.Lear> hector needs to provide text
[15:19:03] <Eliot.Lear> (an example at least)
[15:19:36] <thomasm> I really have a problem with adoption of something as resolved with no list discussion
[15:19:39] <Eliot.Lear> paul hoffman: more examples are better. highlights potential problems
[15:19:50] <Eliot.Lear> thomasm: no issue is resolved
[15:19:54] <Barry Leiba> Mike, there WILL be discussion on the list.
[15:20:04] <Eliot.Lear> ... until there is confirmation on the mailing list
[15:20:10] <Barry Leiba> NOTHING is resolved here without further resolution on the list.
[15:20:29] <thomasm> It's not helping that there's no audio feed
[15:20:30] <Eliot.Lear> Paul Hoffman: to provide some text on what examples he wants to see
[15:20:46] --- harald has left
[15:20:47] --- harald has joined
[15:20:49] --- harald has left
[15:20:58] <Eliot.Lear> 1196
[15:20:58] <Barry Leiba> I'm sorry to hear about the audio problems. :-(
[15:21:13] <Eliot.Lear> upgrade indication and protection against downgrade attacks
[15:21:31] <Eliot.Lear> indicate this is the lowest quality algorithm
[15:21:40] <Eliot.Lear> doug otis:
[15:22:02] <Eliot.Lear> need to decide what signatures we're not going to process
[15:22:37] <Eliot.Lear> in terms of handling local trust, it helps to know who created the signature
[15:23:03] <Eliot.Lear> if we include primary and secondary, if you have a secondary there had better be a primary (?)
[15:23:23] <Eliot.Lear> stephen: can you cover this in your slides tomorrow?
[15:23:25] <Eliot.Lear> doug: okay
[15:24:07] <Eliot.Lear> barry: verify gets to decide which algorithms are acceptable
[15:24:54] <Eliot.Lear> (jon for elliot) paul hoffman: let's not over-engineer things.
[15:25:59] <Eliot.Lear> elliot: the purpose is for the sender to tell the verifier, you should see a signature of a give algorithm they sign with, so the verifier can detect an attack.
[15:26:24] --- joncallas has joined
[15:26:40] --- resnick has left: Replaced by new connection
[15:26:55] --- Eliot.Lear has left
[15:27:15] --- resnick has joined
[15:27:37] --- robsiemb has left: Logged out
[15:27:41] --- robsiemb has joined
[15:27:43] --- lisaDusseault@jabber.psg.com has joined
[15:27:45] --- joncallas has left: Replaced by new connection
[15:28:04] --- Eliot.Lear has joined
[15:28:06] --- joncallas has joined
[15:29:02] <Eliot.Lear> ekr: doesn't matter if the sender communicates because a sucky [sic] algorithm should always be ignored
[15:29:24] --- newcat has joined
[15:29:26] <Eliot.Lear> but it's still a policy decision for the recipient
[15:29:59] --- robsiemb has left
[15:30:00] <Eliot.Lear> russ: the concern is that someone in the middle didn't mess with the message
[15:30:11] <Eliot.Lear> you can do that in any number of ways, dns being one of them.
[15:30:20] --- newcat has left
[15:30:32] <Eliot.Lear> the point is: pick a means of conveying the information to the recipient so he can make his choice
[15:30:45] --- joncallas has left: Replaced by new connection
[15:31:07] <Eliot.Lear> dave crocker: conflict between ekr and russ on this matter. i agree with eric.
[15:31:09] --- joncallas has joined
[15:31:22] --- jis has left: Logged out
[15:32:11] --- Doug_O has left: Replaced by new connection
[15:32:40] <Eliot.Lear> DEFER this until after the signatures.
[15:32:46] <Eliot.Lear> 1200
[15:33:09] <Eliot.Lear> MUST ignore signatures that don't verify
[15:33:09] --- resnick has left: Disconnected
[15:33:16] <Eliot.Lear> this is really a local policy question
[15:33:57] --- resnick has joined
[15:33:57] --- marcos.sanz has left
[15:33:58] <Eliot.Lear> Eric to propose text
[15:34:01] --- marcos.sanz has joined
[15:34:06] <Eliot.Lear> 1201
[15:34:11] <Eliot.Lear> SSP issue
[15:34:17] <Eliot.Lear> 1203
[15:34:25] <Eliot.Lear> extendable RRs
[15:34:36] <Eliot.Lear> what happens to tags when you don't recognize the tags
[15:34:41] --- joncallas has left: Replaced by new connection
[15:34:42] <Eliot.Lear> currently MUST ignore
[15:34:48] <Eliot.Lear> could be reiterated elsewhere
[15:34:48] --- resnick has left
[15:34:58] --- joncallas has joined
[15:35:03] <Eliot.Lear> Editorial- RESOLVED with Editorial text
[15:35:04] <Eliot.Lear> 1204
[15:35:22] <Eliot.Lear> munging white space around colons in headers
[15:35:42] <Eliot.Lear> there's a patch to fix it for sendmail, but not milter
[15:36:00] <Eliot.Lear> tony; there's at least one other implementation - sendmail/milter is not the only implementation that has this issue
[15:36:30] <Eliot.Lear> eric: this is not a serious problem in real world cases. the only two cases that get screwed up are spaces before colons or no spaces after the colon, or tabs
[15:36:42] --- mrichardson has joined
[15:37:04] --- robsiemb has joined
[15:37:09] <Eliot.Lear> Paul hoffman: add wording to 3.4 to discuss this as a choice for canonicalization
[15:37:14] <thomasm> that doesn't help for a receiver
[15:37:16] <Eliot.Lear> Eric agrees
[15:37:57] <Eliot.Lear> Tony: "simple" is where the problems occur. this is where the text is needed.
[15:38:28] <Eliot.Lear> Resolution: ACCEPTED. TEXT to be added
[15:38:34] <Eliot.Lear> ... by Eric
[15:38:37] <Eliot.Lear> 1215
[15:38:48] <Eliot.Lear> clarifications on use of l=.
[15:38:56] <Eliot.Lear> closed.
[15:39:00] <Eliot.Lear> ISSUE CLOSED
[15:39:03] <Eliot.Lear> 1216
[15:39:09] <Eliot.Lear> signature h= and z= tags
[15:39:26] --- klensin has joined
[15:39:28] <Eliot.Lear> Can list of header fields differ?
[15:39:50] <thomasm> mic: I disagree that there should be any correlation between z and h
[15:40:16] <Eliot.Lear> why, mike?
[15:40:24] --- resnick has joined
[15:40:26] <thomasm> because they are performing different functions
[15:40:34] <Eliot.Lear> more, please.
[15:40:39] --- marcos.sanz has left
[15:40:46] --- marcos.sanz has joined
[15:40:59] <thomasm> you may just want to see the thing you expect to break, vs what you want to protect
[15:41:45] <Eliot.Lear> eric: no objection to decoupling the two
[15:41:51] <thomasm> none of mine
[15:42:01] <Eliot.Lear> paul: fewer MUSTs the better
[15:42:29] <Eliot.Lear> jim fenton: doesn't see a need to correlate, except when there are multiple headers of the same name that you're signing.
[15:42:35] --- harald has joined
[15:42:49] <Eliot.Lear> jim: this disambiguates only a corner case
[15:43:28] <Eliot.Lear> paul: this gets tricky if someone decides to use z INSTEAD of h.
[15:43:33] <harald> q (naive): if h and z are lists, and have to have the same content, why give both? It adds no information....
[15:43:48] --- joncallas has left: Replaced by new connection
[15:43:53] <Eliot.Lear> paul: should add additional informational text
[15:43:57] <Eliot.Lear> reminder: if you have a question for the microphone please prefix your comment with MICROPHONE:
[15:44:12] <thomasm> z gives more information than h:
[15:44:12] --- robsiemb has left
[15:44:16] <fenton> harald: h just lists the header fields, z is a copy of the entire header field
[15:44:19] <Eliot.Lear> 1222
[15:44:25] <harald> ok. thanks!
[15:44:26] <Eliot.Lear> ABNF Sender/Originator
[15:44:28] --- joncallas has joined
[15:45:25] <Eliot.Lear> table for now
[15:45:40] <Eliot.Lear> 1224
[15:45:43] <Eliot.Lear> DKIM and mailing lists
[15:45:46] <Eliot.Lear> defer till next session
[15:45:52] <Eliot.Lear> 1226
[15:45:57] <Eliot.Lear> 512 too short?
[15:46:11] --- resnick has left: Replaced by new connection
[15:46:12] <Eliot.Lear> RSA key sizes should be 1024 minimum
[15:46:45] <Eliot.Lear> Paul Hoffman: didn't Russ provide text on this to resolve?
[15:47:05] <Eliot.Lear> Eric: ACCEPT. Use Russ' text with perhaps slight modification
[15:47:08] <thomasm> that was arvel
[15:47:16] <Eliot.Lear> 1227. gnits
[15:47:19] <Eliot.Lear> ACCEPTED move on
[15:47:29] <Eliot.Lear> 1228 why is s= required?
[15:47:41] <Eliot.Lear> RESOLVED answered
[15:47:43] <Eliot.Lear> 1229
[15:47:49] <Eliot.Lear> z= field and EAI wg
[15:48:05] <Eliot.Lear> internationalized email addresses
[15:48:45] <Eliot.Lear> Eric: this is the whole 8 bit header issue
[15:49:08] <thomasm> qp
[15:49:17] <Eliot.Lear> (mike, right)
[15:49:46] <Eliot.Lear> Paul: I volunteer to be an EAI liaison.
[15:49:52] <Eliot.Lear> Dave: close the issue
[15:50:24] <Eliot.Lear> Chris Newman: upgrade to utf-8 for canonicalization ;-)
[15:50:32] --- robsiemb has joined
[15:50:33] <Eliot.Lear> LEAVE OPEN
[15:50:48] <Eliot.Lear> 1230 selectors and key rollover
[15:51:21] <Eliot.Lear> selector is a key name and a key id. is there benefit in pulling the key id?
[15:51:28] <Eliot.Lear> (stephen said that)
[15:52:00] <Eliot.Lear> jim fenton: selector names are arbitrary strings. i don't see a reason to introduce semantics
[15:52:14] <Eliot.Lear> phb: you tie peoples' hands with additional semantics.
[15:52:15] --- joncallas has left: Replaced by new connection
[15:52:35] <Eliot.Lear> john levine: we can do a bcp if this is a good idea
[15:52:51] --- joncallas has joined
[15:52:52] <Eliot.Lear> CLOSE THE ISSUE
[15:52:58] <lisaDusseault@jabber.psg.com> Doesn't the 'i' field have the same requirement as the 'z' field for EAI considerations?
[15:53:18] <fenton> You're right, Lisa
[15:53:28] <thomasm> actually, that's a really good point
[15:53:47] <thomasm> maybe we should say that it need to be qp encoded at the very least
[15:54:09] --- Hollenbeck has left
[15:54:09] --- joncallas has left
[15:54:16] --- joncallas has joined
[15:54:18] --- pguenther has joined
[15:54:20] <fenton> I'm not sure that qp is going to be a good choice for UTF-8 though.
[15:54:24] <Eliot.Lear> 1230 CLOSE
[15:54:31] <Eliot.Lear> 1231
[15:54:42] <Eliot.Lear> problematic references that would hold up base
[15:54:52] --- sm-msk has joined
[15:54:57] <marcos.sanz> qp works, but it is only useful if most of the text to be qp'ed is ASCII
[15:54:59] <Eliot.Lear> Barry: the RR document will go to last call long after the base
[15:55:08] <Eliot.Lear> authentication results already gone
[15:55:27] --- NFreed@jabber.org has left: Replaced by new connection
[15:55:27] --- lisaDusseault@jabber.psg.com has left: Replaced by new connection
[15:55:33] <thomasm> for i= it's probably not that big of a deal since there won't be much to encode
[15:55:35] --- lisaDusseault@jabber.psg.com has joined
[15:55:38] <Eliot.Lear> ยง 6.6 MUA considerations is the text here useful?
[15:55:46] <Eliot.Lear> this probably belongs elsewhere
[15:56:10] <Eliot.Lear> tony hansen: get rid of authentication results?
[15:56:27] <Eliot.Lear> stephen: we can't have a forward reference that is normative
[15:57:02] <Eliot.Lear> stephen: we would have to recharter.
[15:57:12] <Eliot.Lear> russ: "future work in this area is expected"
[15:57:26] <thomasm> mic: I've thought for a long time that DKIM should define its outputs in base, and not use auth-res as that vehicle
[15:57:48] <Eliot.Lear> phb: maybe just whack the RR spec now?
[15:58:33] <Eliot.Lear> barry: can we discuss this on wednesday
[15:58:39] <Eliot.Lear> [a bit of ruckous]
[15:58:54] <sm-msk> no kidding...
[15:58:56] <Eliot.Lear> Dave Crocker: the text in the spec is an example
[15:58:58] --- nsb has joined
[15:59:34] <Eliot.Lear> move details of how the query is done.
[16:00:03] <thomasm> who is speaking?
[16:00:03] --- randy g has left
[16:00:09] <Eliot.Lear> olafur ???
[16:00:14] <Eliot.Lear> chair of dnsext
[16:00:19] --- gshapiro has joined
[16:00:29] <tonyhansen> gulbrandson
[16:00:31] --- nsb has left: Logged out
[16:00:36] --- nsb has joined
[16:00:45] --- pk has left
[16:00:50] <Eliot.Lear> carry over rest of issues till wednesday
[16:00:57] --- George Jones has left
[16:01:04] --- jimsch1 has left
[16:01:04] <Eliot.Lear> please review slides that eric sends out
[16:01:14] --- Barry Leiba has left
[16:01:14] <Eliot.Lear> we're adjourned.
[16:01:19] --- sm-msk has left: Logged out
[16:01:21] --- fenton has left
[16:01:27] --- dcrocker has left
[16:01:35] --- pawal has left
[16:01:35] --- marcos.sanz has left
[16:01:42] --- nov has left
[16:01:49] --- Eliot.Lear has left
[16:01:56] <lisaDusseault@jabber.psg.com> Au reservoir.
[16:01:57] --- robsiemb has left
[16:01:59] --- lisaDusseault@jabber.psg.com has left
[16:02:05] --- pguenther has left
[16:02:06] --- alexeymelnikov has left
[16:02:19] --- yone has left
[16:02:25] --- nsb has left
[16:02:27] --- ogud has left
[16:02:51] --- arvel has left
[16:03:09] --- gshapiro has left
[16:04:04] --- harald has left
[16:04:51] --- stephenfarr has left
[16:05:28] --- joncallas has left
[16:07:15] --- kivinen has left
[16:09:33] --- hardaker has left: Disconnected.
[16:09:47] --- handle has left
[16:11:48] --- ogud has joined
[16:12:45] --- lyndon has left
[16:15:01] --- klensin has left
[16:15:25] --- kmurchison has left
[16:17:29] --- thomasm has left: Logged out
[16:18:34] --- Dennis Dayman has left
[16:19:41] --- jlcjohn has left
[16:22:32] --- marz has left: Disconnected.
[16:24:24] --- tonyhansen has left
[16:27:03] --- harald has joined
[16:28:52] --- harald has left
[16:30:46] --- robsiemb has joined
[16:44:00] --- robsiemb has left: Logged out
[16:45:03] --- robsiemb has joined
[16:45:08] --- robsiemb has left
[17:05:48] --- dcrocker has joined
[17:57:36] --- dcrocker has left
[18:18:45] --- ogud has left
[18:45:00] --- alexeymelnikov has joined
[18:54:49] --- dcrocker has joined
[19:19:15] --- ogud has joined
[19:23:54] --- mrichardson has left
[19:28:54] --- dcrocker has left
[19:29:41] --- ogud has left
[19:57:49] --- dcrocker has joined
[19:59:04] --- dcrocker has left
[20:00:37] --- stephenfarr has joined
[20:12:45] --- stephenfarr has left
[20:56:43] --- alexeymelnikov has left
[21:04:51] --- mrichardson has joined
[21:40:46] --- mrichardson has left: Logged out