[11:15:37] --- john.levine has joined [12:27:36] --- healthyao has joined [13:00:47] --- sftcd has joined [13:01:21] * sftcd has set the topic to: Meeting starting at 17:40 EDT [13:02:28] --- sftcd has left: Computer went to sleep [13:22:01] --- sftcd has joined [13:33:09] --- Phillip Hallam-Baker has joined [13:33:15] --- eric has joined [13:55:12] --- sm has joined [13:55:14] --- Phillip Hallam-Baker has left [14:05:37] --- sftcd has left: Computer went to sleep [14:21:53] --- healthyao has left [14:25:39] --- mike has joined [14:56:17] --- mike has joined [14:56:28] is this thing working? [14:56:48] --- sftcd has joined [14:57:04] are we there? [14:57:08] i'm here [14:57:25] Eliot's gonna arrive & scribe real soon now [14:57:42] We agreed that the Overview WGLC starts today and ends March 24th [14:57:48] Now on Deployment doc Q&A [15:14:44] --- sftcd has joined [15:15:02] * sftcd has set the topic to: DKIM jabber flaking [15:17:40] --- mike has joined [15:17:59] hey look, i'm clapping with one hand [15:21:45] --- tonyhansen has joined [15:23:26] --- mrose@jabber.dbc.mtview.ca.us has joined [15:23:35] --- mrose@jabber.dbc.mtview.ca.us has left [15:26:27] --- jiangxingfeng has joined [15:27:39] --- resnick has joined [15:27:55] mike: Sorry. :-! [15:31:02] --- jiangxingfeng has left: Replaced by new connection [15:33:11] heh... yeah.. it's the practical end of these name changes unfortunately [15:33:17] --- doug.otis has joined [15:33:33] --- sm has joined [15:34:10] --- eliot.lear has joined [15:34:17] hello? [15:34:22] i'm here [15:34:25] cool! [15:34:33] i'll start taking notes [15:34:34] in here [15:34:59] do you need to publish a record for dkim=unknown (1541) [15:35:47] 1542: conflicts with 4871? [15:35:58] 1543 remove FWS [15:36:02] --- john.levine has joined [15:36:23] seems to be back [15:36:27] several possibilities on how to resolve this... [15:36:34] --- Eliot Lear has joined [15:36:54] changing jabber servers... this is eliot [15:37:00] --- eliot.lear has left [15:37:07] peter koch at the mic [15:37:14] --- EronenP has joined [15:37:19] 1547 MX record pulbishing mandate [15:37:30] what was the strong argument against? [15:37:59] jim: it's probably a good practice, but was overreaching [15:38:10] peter: [15:38:23] ASP existence test uses MX [15:39:05] ASP and no MX offers simple signaling. [15:39:31] Avoid tree walkup [15:40:28] --- eric has joined [15:41:08] ASP and no MX signaling would be lost [15:41:15] --- sftcd has joined [15:42:12] we leave 1543 open for now [15:42:42] --- hallam has joined [15:42:44] dave crocker: the original concern was to make it cleaner, but then it made it incompatible with dkim [15:42:57] compatibility overrides cleanliness [15:43:25] jim: interoperability or consistency? [15:43:33] dave: one wants to use the same parser for both [15:44:12] any qs about these issues? [15:44:32] default is close. speak now otherwise [15:45:11] ellen siegel: clarify 1526 [15:45:57] 1519? [15:46:03] arvel: propose to close and leave text alone? [15:46:08] barry: yes [15:46:23] 1519 is not on this list [15:46:33] 1519 comes up in a minute I think [15:46:36] it's 1382 1513 1521 1522 1523 1524 1526 1527 1528 [15:47:47] pete resnick: a non-normative note might be appropriate on 1521 [15:48:01] --- healthyao has joined [15:48:02] the deployment doc would be a better place to put that pete [15:48:17] please say mic: if you want it sent to the mic [15:48:26] no i didn't mean it to the mic [15:49:08] dave crocker: the filtering engines are incredibly complicated, so we can't predict how this stuff will be useful, and so we might bias the doc with examples [15:49:41] I would of course 1547 as well. [15:49:42] close all but 1543 and 1547 [15:49:59] now onto the stickier wickets [15:50:05] mike: ack. [15:51:06] 1544 ASP version numbers? [15:51:22] i'd be happy with the label staying put [15:52:34] 1544 version numbers- no passion- probably closed [15:52:46] 1545 signed v. unsigned header fields [15:53:16] stephen: we need to go back and check that nothing silly is being done because we are looking at an unsigned field. [15:53:20] arvel: [15:53:40] there was a brief discussion using something other than from [15:53:53] But that may not be the identity of the one introducing the message, especially when the signature is ambiguous. [15:54:34] Jim: 1548 and 1549 i don't understand the issues [15:55:44] dave crocker: in trying to get clarity about what ssp was and was not, was trying to get clarity of what security issues were and were not address, the current document doesn't need it because the current doc is sufficiently constrained. [15:55:52] barry: that could go into a deployment doc [15:56:26] jim: hector was suggesting that there be some text about 3rd party sigs [15:57:10] Perhaps Third-party authorization could be handled by TPA_ASP extensions. [15:57:13] phillip: we need to have a good understanding of the threats in order to write security considerations [15:57:48] phillip volunteers to add text in the security considerations section [15:58:10] barry: these issues get closed and phillip can propose text to security considerations [15:58:28] 1551: policy scope v. transit method. does that need to be included? [15:58:33] Clarify that this applies to SMTP only. [15:59:02] Yes. [15:59:46] That is why scope could help in future extensions. [15:59:47] mail to news gateways ... [16:00:17] Policy and not DKIM is being extented. [16:00:24] jim: dkim is not tied to smtp and so why should we do so now? [16:00:36] barry: default action is to close those issues. [16:00:47] what granularity does ASP operate at? [16:00:50] (jim) [16:01:19] --- Phillip Hallam-Baker has joined [16:01:20] early versions of SSP allowed for separations of users [16:01:31] decided early on that it was not appropriate [16:01:39] ASP is always uniform across a domain [16:02:07] which issue is this again? [16:02:23] Restricted keys. [16:02:32] we put into -base the ability to delegate a key for a particular address [16:02:39] does ASP follow that? [16:02:52] opinion #1: dkim is domain level and so should be ASP [16:02:58] MIc: Restricted keys represent a concern irrespective of policy assertions. [16:03:10] ? [16:03:18] desire to use opaque tags [16:04:16] opinion #2: while dkim is mostly a domain level protocol, we still have this capability in -base, and therefore we should reflect this in ASP. [16:04:50] -03 uses opinion #2 [16:05:25] dave crocker: [16:05:28] Mic: What risk is created by accepting a valid non-restricted signature per the domain irrespective of the local-part? [16:05:54] Doug - if eliot reads that I won't understand it, can you rephrase? [16:06:26] dave crocker: it is not clear to me that anything we're doing with ASP is exactly the same semantics of -base. [16:06:38] we don't understand this q that well [16:06:54] very particularly about i= and we seem to have overloaded i= [16:07:10] what is the overriding reason why ASP must use i=? [16:07:19] jim: i'm in #2 camp [16:07:38] What risk does ASP avert by making local-part matches of non-restricted keys non-complaint with "all" policy. [16:07:57] the reason you delegated a key to a particular user was because you were delegating it at a lower level of trust, say for distributing news letter [16:08:17] in the base, if the sig does not say newsletter@example.com, then the sig is invalid [16:08:33] This means valid per rfc4871 is not compliant with "all" although valid and signed by an non-restricted key. [16:08:46] here, if the sig IS valid for newsletter@example.com, and the from address is ceo@example.com, do you really want to call that valid? [16:08:48] i think not [16:08:51] I would say call it a DOMAIN signaturre. [16:08:54] phillip: [16:09:12] but if it's not a valid dkim signature, it won't be considered as an author signature [16:09:14] ?? [16:09:16] right? [16:09:20] 3 parts: message, key record, asp [16:09:36] A non-restricted key means that the signing domain can decide what is compliant. [16:10:05] asp can only be at the domain level, because you won't be able to express complex policy in that record. [16:10:08] If admin:sender signs the message with a from of ceo@example.com is okay. [16:10:56] If the domain signs the message with a non-restricted key, then the check only requires comparison of the domains signature/from [16:11:31] perhaps generate key record that has a null algorithm and an SSP record and then follow that up with ASP records [16:11:55] the only question here is which sigs you consider to be authors and which you do not [16:11:59] Domain signatures and not author signatures. [16:12:13] ASP is about domain signatures. [16:12:37] The exception required would be for restricted keys. These are special without ASP. [16:12:43] barry: [16:12:58] MIC: jim -- a g=newsletter selector would not be able to sign for ceo, so the signature would be invalid, so it wouldn't be a valid author signature [16:12:59] the way asp is currently specified, you might want to look twice? [16:13:02] ASP should not require information be removed from the Signature!!! [16:13:35] ASP requires signatures remain ambiguous! [16:13:37] new mike announcer: pete resnick [16:13:42] This was all solved in base then [16:14:27] The only concern would be whether the domain signed the message. [16:14:30] I'll announce for other than just mike at the mic. ;) [16:14:32] ok [16:14:38] Silly. [16:14:52] Who should decide what the domain signs! [16:15:01] i think i'm with dave that this is all pretty confusing [16:15:08] j.d. falk: this is complex. can we declare this out of scope? [16:15:16] ASP is out of scope then. [16:15:25] jim: it's difficult to fix this later [16:15:30] mic: no, because we have the the ASP defn right first [16:16:05] sorry, have to "get" [16:16:14] Eliot figured that out. [16:16:23] Only the domain matching should be made against non-restricted keys. [16:16:26] dave crocker: do we believe that ASP when it's done will not be extensible? jim no. [16:16:49] dave: so perhaps we could enhance distinguish this within the domain. [16:17:00] Agree with Dave. [16:17:07] dave; this sounds like transaction mail versus marketing mail. [16:17:30] dave: this is why the threat stuff got raised in the first place [16:18:02] dave: basic goal is when someone outside the domain attempts to make unauthorized used. [16:18:10] dave: i= is an internal management issue [16:18:46] dave: we could have a practices enhancement later to address this [16:19:00] Second the motion. [16:19:11] jim: the problem is that we put a mechanism into base that already goes into the internal management. [16:19:44] arvel: what utility is missed if we don't honor i= and g=? [16:19:52] None. [16:20:25] jim: we've given the ability to delegate keys individually, and now whether that individuality is honored or ignored by that ASP [16:20:46] barry: agrees with dave. we don't need to do that now. [16:20:58] barry: issue stays open. [16:21:03] The only except that needs to be made has to do with restricted keys. These must be considered risky when not seen within the From header. [16:21:10] from my perspective it's not my consensus [16:21:24] stephen: if we go down option one we have to document this in security considerations [16:22:00] jim: the other case: if i have a mailing list that i want to separate sig, then the meaning of that sig is preserved. [16:22:06] NEXT [16:22:14] Discardable Practice [16:22:30] which issue # [16:22:58] Do we have the right word itself? [16:23:12] J.D.: with MAAWG hat on. [16:23:34] Yes. [16:23:48] he is convinced that people would take it too literally [16:24:15] chair: 2nd bullet: is discardable appropriate? [16:24:34] j.d.: this is appropriate. and MAAWG seems to have supported this [16:24:41] chair: general agreement in the room [16:25:23] chair: we need to get the deployment advice right in a deployment doc [16:25:40] jim: if they act on discardable, do they generate a bounce or not? [16:25:42] Discardable doe not address the problem statement of requirements draft. [16:26:21] barry: we can be silent [16:26:22] RFC 3464 would ensure these messages are of no value as spam. [16:26:25] doug - which specific requirement? [16:27:06] phillip: we need to have a way for declaratively saying that this address is likely to be fraudulently used. [16:27:23] The RFC 5016 [16:27:37] Phillip adds: we really need it. [16:28:15] doug - can you point at a specific requirement from 5016? [16:28:32] John Levine: Hear demand from senders, but not much from receivers. [16:28:47] JL: Wanted "unimportant". [16:29:04] JL: Self-declaring that you're a fraud target isn't useful. [16:29:07] Then -FraudTarget and -NoBounce are two different flags [16:29:25] JL: So long as it's advice and not a requirement, no problem. [16:29:44] JL: I don't think it's worth taking out. [16:30:04] Jim: Should there be an additional practice between All and Discardable? [16:30:05] At least a sole signer assertion. [16:30:21] Isn't that what all is? [16:30:25] No. [16:30:33] Jim: No.... [16:30:42] Chair: Let's address this first. [16:31:14] PHB: Sounds like we have two different flags: 1) Supress bounces; 2) I'm a fraud target. [16:31:26] PHB: -ALL is not sufficient. [16:31:31] Agree with Phillip. [16:32:01] PHB: I might not want a bounce report from bounce mechanism; want something else. [16:32:19] Eliot: Not clear of the value since we're not going to be listened to anyway. [16:32:42] Chair: There sounds like support for keeping it. [16:32:53] Eliot: WRT the word, "Get on with it". [16:33:04] * resnick passes the keyboard back to Eliot [16:33:10] Ellen: we need guidance on how this word will be used. [16:33:25] Discard is understood action. [16:33:32] Discard. [16:33:51] Murray: discardable has special meaning sometimes. There has been interest in getting the kind of reports that phillip mentioned. [16:34:05] the individual -dkim-reporting draft goes there [16:34:07] Agreed. Sole signer assertion. [16:34:19] Barry: as chair, it's out of scope for the working group. [16:34:30] where that "it's" is reporting [16:34:39] murray: can we charter to cover that? [16:34:58] pasi is the new area director [16:35:00] But this this remains a problem regarding the likely result of discardable as an assertion. [16:35:47] chair: in principle we could recharter, but i would prefer not to [16:36:03] pasi: let's finish asp first and THEN recharter [16:36:15] that also gives me time to figure out these acronyms [16:36:43] Solve RFC 5016 3.2. Problem Scenario 2: Illegitimate Domain Name Use [16:37:11] chair: resolution for this issues 1520 and 1546 close 1520 and 1546, and that we open a new issue on the issue name. [16:37:26] Perhaps two assertions would be better. [16:37:45] chair: there are valid reasons that the word "discardable" could cause confusion. the new issue will close 2 weeks after the end of this meeting. [16:37:56] chair: this issue only will address the name. [16:38:17] jim: upward search relative to iab draft [16:38:55] Empty ASP records and MX record requirement could avoid the domain search. [16:38:57] similar situation there as with the use of txt records. we're making a considered decision. [16:39:02] and we should go forwrad [16:39:34] I have read the IAB document [16:40:25] chair: please see doc. [16:40:32] These records are to be used on highly abused domains. Get ready to be hammered by domain tree walking. [16:40:41] stephen: we'll compare this with 5016? [16:40:53] jm: yes [16:41:02] as far as i can tell, it satisfies it [16:41:09] i can do that [16:41:37] peter: independent of the iab draft, even one step tree walking is violating fundamental architectural properties of dns. and i consider it plain wrong. and i will raise it in last call. [16:41:42] chair: do you have an alternative? [16:41:58] MX and ASP is an alternative. [16:42:09] peter: don't try and use a client-side mechanism where it doesn't exist. [16:42:44] Require the domain seeking protect to do the work. [16:42:59] jim: we have a threat that we are trying to address. we recognize that the upward look is addressing a threat, and we recognize that we are potentially crossing an administrative boundary, and we believe we are trading a higher risk for a lower risk [16:43:04] MIC: as input to peter, I'm seeing a lot of wildcarded domains with SPF records which I think is the failure mode of the tree walk? [16:43:38] phillip: we could fix this with xptr [16:43:50] --- EronenP has left [16:43:51] Wildcard are a solution? [16:44:26] Existences everywhere meets non xptr policies. [16:44:35] if DNS weren't designed to do this sort of thing, then they never would have created the "search" properties in the specified resolver. [16:44:54] peter doesn't understand mike's comment [16:45:14] rfc 1536 discourages excessive searches, but certainly not more than one level. [16:45:29] my comment is about whether it's working the way we intend for the domains we want it to work for [16:46:38] we're done [16:46:43] adjourned [16:46:46] --- Eliot Lear has left [16:46:46] --- hallam has left [16:46:46] --- Phillip Hallam-Baker has left [16:46:54] --- resnick has left [16:47:11] --- eric has left [16:47:53] --- sftcd has left [16:49:44] --- mike has left [16:51:12] --- healthyao has left [16:55:08] --- john.levine has left [17:02:11] --- sm has left [17:12:00] --- tonyhansen has left [18:02:40] --- doug.otis has left [18:04:09] --- doug.otis has joined [18:57:23] --- healthyao has joined [18:59:37] --- healthyao has left [19:26:15] --- healthyao has joined [20:27:06] --- john.levine has joined [20:27:24] --- john.levine has left [20:34:01] --- healthyao has left [21:01:27] --- doug.otis has left