[01:36:09] --- dcrocker has left
[03:52:41] --- tonyhansen has joined
[03:54:54] --- pigdog has joined
[03:56:25] <pigdog> Good morning. This is the jabber working group, and I am Eliot Lear. Arvel Hancock and I will scribe into the jabber session. If you wish something said at the microphone, please preface your comment with "MIKE:".
[03:58:33] --- Stephen Farrell has joined
[03:59:19] --- fenton has joined
[03:59:28] --- cnewman@jabber.org has joined
[03:59:42] <fenton> I thought this was the dkim working group, not the jabber working group
[03:59:48] <pigdog> oops
[03:59:57] <pigdog> indeed
[03:59:57] <pigdog> indeed
[04:01:16] <pigdog> we are waiting a few minutes for others to show up
[04:01:48] <pigdog> ok, for the record - this is the DKIM working group and I need more caffeine
[04:02:54] <pigdog> we are beginning
[04:03:00] <pigdog> welcome
[04:03:05] <pigdog> stephen farrell:
[04:03:13] <pigdog> goals of the day:
[04:03:21] <pigdog> finish up work on SSP rewquirements
[04:03:25] <pigdog> progress SSP work
[04:03:29] <pigdog> milestones revision
[04:03:30] --- tim.polk has joined
[04:03:50] --- Dave Cridland has joined
[04:03:55] <pigdog> want a plan to have draft-ietf-dkim-ssp-00
[04:04:00] <pigdog> agenda:
[04:04:04] <pigdog> bashing
[04:04:06] <pigdog> doc status
[04:04:08] <pigdog> ssp requirements
[04:04:10] <pigdog> ssp plans
[04:04:10] --- menno has joined
[04:04:12] <pigdog> some ssp issues
[04:04:14] <pigdog> ssp discussion
[04:04:15] <pigdog> overview
[04:04:19] <pigdog> vouch by reference
[04:04:20] <pigdog> aob
[04:04:46] <pigdog> any bashing?
[04:04:55] <pigdog> none heard. moving on
[04:04:57] <pigdog> doc status
[04:05:07] <pigdog> draft-ietf-dkim-base-10 is with rfc editor
[04:05:18] <pigdog> ssp-reqs-03 is in WGLC. very little comment
[04:05:26] <pigdog> may extend WGLC by a week.
[04:05:26] --- eric has joined
[04:05:52] <pigdog> eric allman:
[04:06:02] <pigdog> there is a problem with the way whitespace is specified.
[04:06:12] <pigdog> there is difference between 822 and 2822
[04:06:45] <pigdog> they disallow CRLF WS CRLF. there is an argument that we need to fix this problem.
[04:06:50] --- hallam has joined
[04:07:29] <pigdog> eric doesn't see this as a showstopper and would prefer not to slow things down. maybe an AUTH48 warning in an informative note.
[04:07:39] <pigdog> eric would like to move as fast as possible, so that he can have a life again
[04:07:49] <pigdog> jim fenton:
[04:08:02] <pigdog> what about KEY records that have embedded CRLFs?
[04:08:14] <pigdog> eric: that got resolved on list, did it not?
[04:08:57] <pigdog> if you're in a KEY record and you put CRLF in the middle of a base64 string you needed to add a space. So that means there's a restriction that doesn't need to be there but there's no harm.
[04:09:01] <pigdog> phb:
[04:09:35] <pigdog> not huge potential for bad thing to happen.
[04:09:52] <pigdog> eric:
[04:10:06] <pigdog> yes, the dns is annoying but we'll fix it next time.
[04:10:49] --- aaronstone has joined
[04:11:36] --- sm-msk has joined
[04:12:38] <pigdog> text proposed for crlf ws crlf as an informative note. that will be added
[04:12:48] <pigdog> jim fenton will now channel mike thomas:
[04:13:10] <pigdog> SSP requirements -03
[04:13:18] <pigdog> in WGLC
[04:13:18] --- raeburn@mit.edu has joined
[04:13:39] <pigdog> current status
[04:13:47] <pigdog> much wordsmithing
[04:13:55] <pigdog> removed provisional requirements except Phil's
[04:14:00] <pigdog> 2 open issues
[04:14:06] --- kjetilho has joined
[04:14:14] --- barryleiba has joined
[04:15:19] <pigdog> slides are available at http://tools.ietf.org/wg/dkim/agenda?item=agenda68.html
[04:15:28] --- ajsaf@jabber.org has joined
[04:15:31] <pigdog> issue 1399: subdomain attack
[04:15:54] <pigdog> suppose bigbank.com
[04:16:17] <pigdog> the attacker uses statements.bigbank.com
[04:16:49] <pigdog> search algorithm of a subdomain walk is potentially costly
[04:17:04] <pigdog> there will be no SSP record for statements.bigbank.com
[04:17:37] <pigdog> so one could walk back to bigbank.com to look for an SSP record.
[04:18:10] <pigdog> dave crocker:
[04:18:22] <pigdog> what is the requirement text?
[04:18:26] <pigdog> (we're now searching)
[04:19:02] <pigdog> page 13 in current draft. #4 at the bottom
[04:19:06] --- thomasm has joined
[04:19:55] --- thomasm has left: Replaced by new connection
[04:20:37] <pigdog> patrik fältström: is this the case of repeated queries?
[04:20:48] <pigdog> jim: how common are wildcards?
[04:21:37] <pigdog> patrik: which protocol are you using? yours or the underlying dns. enum also hit this same problem. iab is looking at this problem.
[04:22:14] <pigdog> jim:
[04:22:44] <pigdog> we aren't using wildcards, but it has to recover from other peoples' use of wildcards.
[04:22:57] <pigdog> stephen: let's go back to solutions later
[04:23:01] <pigdog> phb:
[04:23:16] <pigdog> keep requirement in a qualified form
[04:23:39] <pigdog> recognizing that if you have a.b.c.z.bigbank.com it probably is going to thrown out by a phishing filter as stupid anyway
[04:23:49] <pigdog> jim: what phishing filter does this?
[04:24:14] <pigdog> phb: it's not important that you be able to express absolutely every name in the dns.
[04:24:17] <pigdog> dave crocker:
[04:25:04] <pigdog> if example.com wants to make a statement, it wants to make a statement for itself and everything above, could an attacker force a walk up a tree.
[04:25:25] <pigdog> jim: possible new RR or _
[04:25:45] <pigdog> dave: reasonable requirement, but i'm not sure we know how to implement it if one believes new RRs are problematic
[04:26:06] <pigdog> dave; let's have requirements that are achievable.
[04:27:23] <pigdog> patrik, eliot: don't take requirement document as gospel
[04:27:54] <pigdog> phb: applying a policy to a whole tree goes beyond what DNS was designed to do
[04:28:06] <pigdog> Dave Crocker:
[04:29:06] <pigdog> as long as we have an understanding that requirements aren't gospel. but then there is the IESG who can take things literally.
[04:29:59] <pigdog> stephen: we need to take an action to propose a wording change to add "if we can't meet it, why not..."
[04:30:04] <pigdog> Issue 1386
[04:30:46] <pigdog> requirements around signatures and combinations of signatures. (a) transitions
[04:30:55] --- thomasm has joined
[04:30:57] <pigdog> (b) restrictions on particular selectors
[04:31:24] <pigdog> jim: thinks that all of these require lookup per message
[04:31:27] <pigdog> phb: no
[04:31:37] --- geoff has joined
[04:31:46] <pigdog> phb: as a receiver, if you find any receiver that is acceptable to you, you accept the message
[04:31:59] <sm-msk> any signature?
[04:32:02] <pigdog> so if you accept RSA+eliptic, for instance and you see either, you accept the message
[04:32:27] <sm-msk> or key
[04:32:43] <pigdog> if you do not accept a particular signature, say rsa512 but there's also ecc, then you can accept ecc.
[04:33:58] <pigdog> jim: trying to solve problem of publishing a week key?
[04:34:42] <pigdog> phil: publishing a key that at the moment is considered ok, publishing a new key with new alg can invalidate policy
[04:34:50] <pigdog> jim: don't understand how this works
[04:35:10] <pigdog> eric: how can this be an attack?
[04:35:12] <thomasm> mic: I don't understand the attck either
[04:35:43] <pigdog> eliot: need to step though the cases.
[04:36:03] <pigdog> eliot: lets go through use case and see where the attack is.
[04:36:24] <pigdog> stephen: lets defer until Phil's slides come up later in the meeting
[04:37:13] <pigdog> jim: please submit suggestions, and also see if we can represent what those who are not email professionals would add
[04:37:31] <pigdog> stephen: last call was to end on friday, but we'll extend by one week
[04:37:48] <pigdog> now, jim fenton as jim fenton:
[04:37:55] <pigdog> draft-allman-dkim-ssp-02
[04:38:11] <pigdog> screwed up slide on presentation
[04:38:17] <pigdog> recent changes
[04:38:24] <pigdog> stephen:
[04:38:52] <pigdog> there were four proposals on the table with SSP. hector has withdrawn his. jim and phil are trying to merge theirs.
[04:39:01] <pigdog> the plan now is to aim for that as a WG draft.
[04:39:05] --- kjetilho has left
[04:39:21] <pigdog> that is the context for this talk and phil's next set of slides
[04:39:34] <pigdog> so, changes in the works on this draft:
[04:40:21] <pigdog> removal of "user" policy. this was an attempt on a domain by domain basis down to the granularity of localparts. it implies a lot of lookups that are not particularly cachable
[04:40:42] <pigdog> tagnames in the policy
[04:40:47] <pigdog> p-> dkim
[04:40:52] <pigdog> t -> dkimflag
[04:41:18] <pigdog> idea is to be more descriptive.
[04:41:39] --- joonhyung.lim has joined
[04:41:50] <pigdog> last ietf there were some problems with -02 algorithm, particularly with subdomain walk
[04:41:55] <pigdog> open ssp issues
[04:42:05] <pigdog> new DKIMP resource record vs TXT record
[04:42:12] <pigdog> "strict" policy
[04:42:40] <pigdog> (not only do we sign our messages, but you should expect to receive our messages intact)
[04:43:22] <pigdog> this is for domains that would rather have messages flagged as "bad" rather than have a really bad message delivered.
[04:44:03] --- dcrocker has joined
[04:44:10] <pigdog> barry lieba: this is advice to the verfier that you should seriously consider breakages
[04:44:20] <pigdog> other open issues:
[04:44:28] <pigdog> limiting choice of selectors
[04:44:49] <pigdog> policies on multiple signatures to aid algorithm transitions
[04:45:00] --- dcrocker has left
[04:45:01] <pigdog> use of PTR/XPTR to get around wildcards
[04:45:06] --- dcrocker has joined
[04:45:09] <pigdog> new ssp algorithm:
[04:45:39] <pigdog> 1. if a valid original sig exists, the message is not suspicious and the algorithm terminates
[04:46:13] <pigdog> 2. (address wild cards here)
[04:46:42] <pigdog> goal is to not to have to publish policy records for every A record in the zone.
[04:47:21] <pigdog> there are two versions, one that uses a new RR and another that uses a TXT record with a prefix
[04:48:03] <pigdog> if we get an NXDOMAIN response, the domain that mail came from does not exist and the message is "suspicious" (fails the policy check).
[04:48:41] <pigdog> if you get a NODATA response, there may be a wildcard.
[04:48:56] <pigdog> so you don't know if the domain doesn't exist or the policy doesn't exist
[04:49:10] <pigdog> so, start to walk up the tree
[04:49:41] <pigdog> if there is a table to limit the upward search (like .com, .co.uk) stop there.
[04:49:56] <pigdog> walk up the tree until we get to a policy record or until we get to a non-signing level
[04:50:16] <pigdog> this could involve a number of lookups if a parent has a wildcard.
[04:50:26] <thomasm> mic: what kind of wildcard? like an mx record?
[04:51:04] <pigdog> jim: any type of wildcard
[04:51:07] <pigdog> peter koch:
[04:51:13] <pigdog> this could happen at other times
[04:51:35] <pigdog> i have problems with tree walking, and with your stop condition
[04:52:00] <pigdog> what is a tld, for instance? that can be a "strange" problem. could be a 2nd level or 3rd level.
[04:52:18] <thomasm> mic: mx wildcards are very common though.. does that negate the value?
[04:52:20] <pigdog> jim: i'd welcome ideas
[04:52:47] --- fujiwara has joined
[04:53:25] <thomasm> no, does it negate the value of this algorithm
[04:54:19] <pigdog> someone: tree walking is a bad idea
[04:54:50] <pigdog> peter: this is just pushing the problem.
[04:55:02] <pigdog> the tld operators are not paid for tree climbing
[04:55:49] <pigdog> someone: you're trying to do a search, and dns system does lookups
[04:55:57] --- Jelte has joined
[04:55:58] <pigdog> phb: i agree with all the above
[04:56:27] <pigdog> there are two issues:
[04:56:43] <pigdog> 1. you can't have a wildcard on a prefix record. you can't have _label.*.whatever
[04:56:56] <pigdog> that's that XPTR and DKIMP address directly
[04:57:30] <geoff> "someone" == Lars Liman
[04:57:44] <pigdog> thanks
[04:57:48] <geoff> np
[04:57:59] --- abelyang has joined
[04:58:41] <pigdog> jim: answering mike thomas: it makes this requirement more onerous
[04:58:50] --- kjetilho has joined
[04:59:42] <pigdog> one way of doing this is to publish a policy that flows downward.
[05:00:18] <pigdog> peter koch: this is just a provisioning issue.
[05:00:32] <pigdog> one should not think of someone maintaining their zones with vi or emacs
[05:01:14] <pigdog> phb: if you see dkim signers are likely to see the value of DNSSEC then you can probably get this problem solved.
[05:01:23] --- jschmid has joined
[05:01:25] <pigdog> there have been discussions about DNSEXT about this problem
[05:01:37] <pigdog> how do you match the tactical with the strategic?
[05:01:39] --- kjetilho has left
[05:02:40] <pigdog> dave crocker: complex things don't tend to succeed. in particular, the global dns administrators need to understand and support this.
[05:03:05] <pigdog> at the least, at the point we have to have discussions about DNS subtleties, we've moved into experimental.
[05:03:53] --- anabolism@jabber.org has joined
[05:04:59] --- anabolism@jabber.org has left
[05:05:06] --- randy has joined
[05:05:09] --- onakayu has joined
[05:07:33] --- kdz has joined
[05:09:52] <pigdog> sorry was at the mike
[05:10:13] <pigdog> discussion about whether a header would help (answer is no)
[05:10:24] <pigdog> barry lieba
[05:10:32] <pigdog> our dns administrators do not understand dns
[05:10:44] <pigdog> there are people who do but that's not them
[05:10:46] <pigdog> so it should be straight forward
[05:10:58] --- kjetilho has joined
[05:11:13] <pigdog> peter koch:
[05:11:38] <pigdog> problem arises from the attempt to fall back to multiple levels of x.y.z.bigbank.com
[05:13:23] <pigdog> jim: as our deployment increases, there should be less need for SSP
[05:13:32] <pigdog> peter: keep deployment phase short ;-)
[05:14:13] <pigdog> the difficulty is all in legacy email
[05:14:23] <pigdog> and the default has to be for now that they don't necessarily sign
[05:14:41] <pigdog> it'd be a whole lot easier to say that you don't sign
[05:14:49] <kjetilho> I think Peter said that if you add a wildcard MX, you can just add a wildcard DKIMP to solve the problem (the same is true for any MX RR)
[05:15:15] <pigdog> phb:
[05:15:41] <pigdog> implementing wildcards with a macro processor is easier than adding new RRs. we have the converse here
[05:16:09] <pigdog> arvel:
[05:16:15] <pigdog> are there good use cases for this?
[05:16:36] <pigdog> i could see a.b.c.d.com looking up b.c.d.com
[05:17:14] <pigdog> jim: the issue is what the table that we stop the search at?
[05:17:18] <pigdog> and there isn't one
[05:18:08] <pigdog> the problem is worse with txt records because if you get an NXDOMAIN you have to try the unprefixed query to determine whether the domain or policy exists
[05:18:19] <pigdog> now phb:
[05:18:25] <thomasm> mic: keep in mind that all of this discussion is pertinent to req 5.1.4 and its finessing
[05:18:32] <pigdog> DKIM polciy proposals
[05:18:37] <sm-msk> req?
[05:18:42] <thomasm> requirement
[05:19:42] <pigdog> phb: so these are policy attacks
[05:20:08] <pigdog> when you have a policy in your protocol, you have authenticated, compliant with policy but unauthenticated, and not compliant
[05:20:22] <pigdog> the policy exists for the case where you are not authenticate
[05:20:26] <pigdog> (d)
[05:20:47] <pigdog> if you can prove the email is authentic, you don't need policy
[05:20:57] <pigdog> you only look at policy where you have not sufficiently authenticated the message
[05:21:25] <pigdog> so policy differentiates the case where there wasn't any authentication or the authentication was bogus or didn't exist
[05:21:27] <pigdog> eric allman:
[05:22:03] <pigdog> are you saying, that the mere existence of a signature effects your policy?
[05:22:08] <pigdog> phb: no
[05:22:54] <pigdog> phb: the policy needs to be "i sign all messages in manner x or manner y"
[05:23:06] <thomasm> mic: can we please outline the attack in detail?
[05:23:30] <pigdog> phb: policy is not constrained by base
[05:23:38] <sm-msk> thomasm: will ask when eric is done
[05:24:03] <pigdog> phb: for policy to mean anything, you have to determine i am compliant or not compliant
[05:24:31] <sm-msk> regardless of the signature's validity
[05:24:46] <pigdog> barry: this is unsolved. check policy. policy says you may have a signature that you don't understand.
[05:25:42] <pigdog> suppose there is a message that is signed with an ECC key. if i don't understand, do i reject the message out of hand? especially if the policy is to sign every message?
[05:25:52] <sm-msk> thomasm: still want me to ask that, or is phb saying enough?
[05:26:11] <thomasm> hold on...
[05:26:14] <sm-msk> ok
[05:26:18] <pigdog> if i accept the message as compliant, then someone who wants to spoof the message merely needs to insert a bogus key
[05:26:51] <pigdog> so all of this boils down to how you navigate a transition.
[05:27:13] <pigdog> this could be wrt keys or canonicalization algorithms
[05:27:24] <thomasm> mic: I don't see the problem: if you have a signature you can't verify, you just ignore it and move to the next
[05:28:07] <pigdog> not talking about base
[05:28:09] <pigdog> barry:
[05:28:22] <thomasm> mic: and then do what???
[05:28:31] <pigdog> the policy tells you to go back and consider the signature in some way even if you not understand it
[05:28:32] <sm-msk> i think he's asking that
[05:29:18] <kjetilho> slide says: unsupported algorithm MUST be treated as valid
[05:29:20] <pigdog> if i only sign with ECC, and that's what my policy says, then anyone can fake my messages
[05:29:50] <pigdog> barry: i'm not accepting this as a signed message
[05:30:38] <pigdog> phb: if you're publishing key records for an unsupported algorithm, what are you supposed to do?
[05:31:14] <pigdog> barry: don't accept the signature and treat the message as unsigned
[05:31:21] <pigdog> phb: but is it compliant or not compliant
[05:31:25] <pigdog> barry: i can't tell
[05:31:27] <thomasm> mic: it's a distinction without a difference, a receiver would be foolish to draw a distinction
[05:31:42] <sm-msk> thomasm: queue at the mic, will get yours in
[05:32:06] <pigdog> phb: you've now created an additional bucket that might be "better"
[05:32:53] <pigdog> phb: a better choice would be to provide advice to the verifier, indicating that there should have been another signature.
[05:33:18] <pigdog> policy must express that I signed twice
[05:33:28] <dcrocker> Folks, I'm probably missing something basic here, but it seems to me that the real problem is the idea that there is a policy statement of what algorithms are supported; if that policy does not exist, then we have no attack. No?
[05:33:31] <sm-msk> thomasm: advise after last slide if you still want me to ask that
[05:34:09] <sm-msk> dcrocker: if the policy exists and describes an unsupported algorithm with which the message appears to be signed, what can the receiver conclude?
[05:34:27] <pigdog> now a matrix on screen that indicates success or failure of the algorithm
[05:34:32] --- kdz has left
[05:35:29] <dcrocker> "if the policy exists". My point is that there is no problem if this kind of policy is not part of SSP. In other words, I'm not seeing what the *benefit* is in having a publication of what algorithms are supported, but it is clear that there is an *attack* that is created by having the capability./
[05:35:34] <pigdog> implicit in "i always with DKIM" is "i always sign with a certain selector set"
[05:35:48] <pigdog> so the proposed change is to list the set of selectors that you sign with
[05:36:13] <pigdog> and this gets you to compliant or not compliant
[05:36:35] <pigdog> stephen: we can't punt on this issue - 1386
[05:37:27] <dcrocker> Selector? Selectors are not supposed to be about signature semantics. The domain name without the selector is./
[05:37:55] <pigdog> stephen and phil are now debating over whether to get to solutions prior to accepting the requirement
[05:37:57] <pigdog> jim fenton:
[05:38:15] <pigdog> do we want to make a distinction between outcome 2 and outcome 3?
[05:38:37] <pigdog> phb: compliant and not compliant are the equivalent of suspicous and not suspicious
[05:39:10] <pigdog> fenton: talking about algorithm transition, with weak rsa and strong ecc, for example
[05:39:26] <pigdog> so you begin signing with ecc, as well as rsa.
[05:39:54] <pigdog> the first part of the transition isn't a problem because you have a valid rsa sig
[05:40:14] <pigdog> this is base
[05:40:50] <thomasm> can we please stick to exactly one attack scenario???
[05:42:02] <pigdog> on the other side of the transition, you should not remove the rsa key until you're seeing overwhelming recognition of the ecc key
[05:42:16] <pigdog> given that there's overwhelming recognition, the breakage is small
[05:42:34] <pigdog> phb: s/mime has this problem
[05:42:42] --- shpark has joined
[05:42:48] <pigdog> it is not viable for email authentication, because 2% don't implement it
[05:43:35] <pigdog> now a debate between jim and phb about whether the 2% matters, and whether we could have multiple transitions
[05:43:56] <pigdog> jim: i don't think this is a policy problem. they won't be removing old signatures so fast.
[05:44:13] <ajsaf@jabber.org> even if you have the policy, don't you have the problem that you're never going to be able to delete the alg.s anyway?
[05:44:45] <ajsaf@jabber.org> (or do we just not care that some people won't upgrade & get the new alg. Or is that what this debate is saying?)
[05:44:50] <thomasm> that's pretty much my take, yes... or just ignore the old broken receivers
[05:45:03] <pigdog> phb: the whole purpose of policy is to navigate transitions
[05:45:34] <pigdog> barry: how does this allow sender to stop signing with the old sig?
[05:47:17] <pigdog> phb: old implementations would see the world as compliant.
[05:47:27] <pigdog> (eliot: i think that's what he is saying)
[05:47:56] <thomasm> and this leads to a huge hole where an attacker just spoofs the bogus new algorithm
[05:48:27] <thomasm> all this seems to be doing is obfuscating the problem, not solving it
[05:48:35] <pigdog> phb: you get smooth transitions
[05:48:37] <kjetilho> the issue is, when you start using a new unknown algorithm, you can spoof e-mail signed with that algo only -- and it will be accepted.
[05:48:57] <kjetilho> sorry, the first "you" should be example.com
[05:49:07] <thomasm> right -- and that's an even worse situation than the old algorithm
[05:49:07] <Dave Cridland> Kjetil/Thomasm: It certainly appears that way to me.
[05:49:13] <sm-msk> why would it be accepted?
[05:49:27] <Dave Cridland> I suspect that sites would upgrade way quicker if email started bouncing, actually.
[05:49:28] <thomasm> ask phill... that's what he seems to be wanting
[05:49:28] <kjetilho> because it's an unknown algorithm, but the keys exist
[05:49:32] <pigdog> questions from barry:
[05:50:07] <dcrocker> "when you start using a new unknown algorithm, you can spoof e-mail signed with that algo only -- and it will be accepted"... how can it be accepted if the algo is unknown. If the algo is unknown, then the recipient cannot perform validation.
[05:50:16] <sm-msk> right
[05:50:28] <sm-msk> that wouldn't be validated though
[05:50:38] <sm-msk> i guess it would be "compliant but not authenticated"
[05:50:38] <pigdog> Is 1386 a MUST/MAY/MUST NOT?
[05:50:40] <thomasm> there seems to be wanting their cake and eating it too going on here
[05:50:41] <kjetilho> exactly what is 1386?
[05:50:54] <thomasm> it's this issue kjetillo
[05:50:55] <pigdog> kj: this question
[05:51:31] <sm-msk> i don't see what "compliant but not authenticated" tells you. i would probably consider it unsigned.
[05:51:32] <pigdog> jim: will this be a problem from a dns management standpoint in terms of listing selectors in the policy record?
[05:51:38] <pigdog> phb: i don't think so
[05:51:39] <kjetilho> yes, but stated which way? hard to know if I'm NOT or not :)
[05:52:07] <thomasm> my bet is that distinction is actually harmful, murray
[05:52:27] <sm-msk> why?
[05:52:31] <sm-msk> what else could i conclude?
[05:52:50] <sm-msk> dave crocker: policy is published under a particular selector?
[05:52:53] <thomasm> if you did conclude... that would only mean that you gave it better treatment which would be a bad idea
[05:53:12] <sm-msk> better than what?
[05:53:24] <thomasm> than if there were no signature
[05:53:33] <sm-msk> how are they different?
[05:53:35] <sm-msk> eliot lear:
[05:53:45] <thomasm> they aren't... that's the problem with this proposal
[05:53:46] <dcrocker> This term "compliant but not authenticated" makes no sense to me.
[05:53:53] <sm-msk> anything that requires any changes in DNS is addition additional administrative overhead; guaranteed people will get it wrong
[05:53:53] --- msj has joined
[05:54:07] <Dave Cridland> dcrocker: It means "Spoofable", I think.
[05:54:09] <sm-msk> thomasm: i agree, i don't think they're any different
[05:54:26] <sm-msk> dcrocker: i don't know the difference between "compliant but not authenticated" and "unsigned"
[05:54:36] <sm-msk> as an implementer, i'd treat them the same i think
[05:54:43] --- msj has left
[05:55:10] <thomasm> me too... that's why I think this might be harmful to draw this distinction -- that we developers might feel inadequate if we didn't come up with a difference
[05:55:15] <Dave Cridland> sm-msk: Actually, there is a difference. "unsigned"/"Non-compliant" means "Badly spoofed", whereas "compliant but unauthenticated" means "Well spoofed".
[05:55:17] <thomasm> which is exactly the wrong thing
[05:55:17] <dcrocker> DC: thanks, but I still do not understand. What, exactly, does it mean to be compliant, if there is no valid signature?
[05:55:35] --- msj has joined
[05:55:37] <sm-msk> dave cridland: yeah but i don't consider either a "pass"
[05:55:45] <kjetilho> you don't KNOW if the signature is valid
[05:55:47] <sm-msk> right
[05:55:54] <ajsaf@jabber.org> dcrocker: compliant with the policy that the originator publishes
[05:56:07] <Dave Cridland> sm-msk: You don;t think we should accept spoofed mail even if the spoofer tried *really* hard?
[05:56:12] <sm-msk> eliot lear: i'm not sure how DNS caching semantics will impact this proposal
[05:56:20] <ajsaf@jabber.org> i.e. the message looks like something you said you were going to do, but I can't be sure because I don't know the algorithms
[05:56:33] <sm-msk> dave cridland: of course not
[05:56:41] <ajsaf@jabber.org> i'm with thomasm -- this is actually worse than "no signature"
[05:56:44] <sm-msk> what ajsaf said
[05:56:53] <sm-msk> +1
[05:56:56] <sm-msk> questions:
[05:57:10] <sm-msk> 1) is 1386t a MUST? 2) is it a MUST NOT? 3) is it a MAY?
[05:57:25] <thomasm> (2) for me
[05:57:26] <pigdog> please state your opinions in terms of those numbers
[05:59:24] <sm-msk> restated: 1) keep the requirement, 2) dump the requirement, 3) make the requirement optional
[05:59:30] <thomasm> (2)
[05:59:56] <shpark> <shpark> (2)
[06:00:22] <pigdog> no consensus
[06:00:39] <pigdog> there will be a strawpoll on the list.
[06:00:56] <pigdog> moving on to Tony Hansen
[06:01:01] <pigdog> DKIM Overview
[06:01:59] <pigdog> tony hansen:
[06:02:21] <pigdog> describes generic architecture
[06:02:45] <pigdog> status
[06:02:45] <pigdog> version 4
[06:03:07] <pigdog> should we publish now v. later
[06:03:10] <pigdog> no consensus
[06:03:16] <pigdog> a few issues worth considering:
[06:03:24] <pigdog> 1. It's too !@#$@# big
[06:03:34] <pigdog> 2. but what about describing ...
[06:03:39] <pigdog> Hmmmm
[06:03:54] <pigdog> We can use some of this stuff now
[06:04:07] <pigdog> it can all wait till later
[06:04:10] <pigdog> hmmm
[06:04:22] <pigdog> don't bother us right now, we want to work on ssp
[06:04:33] <pigdog> charter; we're supposed to worry about it now
[06:04:36] <pigdog> hmmmm
[06:04:53] <pigdog> current overview does not cover ssp well. it couldn't
[06:05:06] <pigdog> another view of overview
[06:05:22] <pigdog> there is a framework piece to this with information on ssp
[06:05:36] <pigdog> we really need to do know what the ssp requirements are going to be, but we don't need to know final details
[06:05:55] <pigdog> deployment guide for base
[06:06:08] <pigdog> and that's done
[06:06:21] <pigdog> deployment guide for ssp isn't done becasue we don't yet know what ssp is yet
[06:06:34] <pigdog> an idea
[06:06:38] <pigdog> split doc up
[06:06:45] <pigdog> publish pieces as they become useful
[06:06:57] <pigdog> now that base is done, publish base deploiyment guide asap
[06:07:23] <pigdog> when the other parts are done, publish them
[06:07:39] <pigdog> Advantages: pieces would be more focused
[06:07:44] <pigdog> pieces can be more timely
[06:07:53] <pigdog> spread impact of other wg work
[06:07:55] --- kjetilho has left
[06:07:59] <pigdog> pieces would be more useful
[06:08:45] <pigdog> impact
[06:08:52] <pigdog> tweaks the milestone list on the charter
[06:09:08] --- jschmid has left
[06:09:10] <thomasm> mic: one thing we need to be careful about is BCP kinds of editorializing in overview: either it is a BCP and needs to wait till we have experience, or delete them from the overview draft
[06:11:07] <pigdog> dave recommits the entire author team to continue the work
[06:12:28] --- kjetilho has joined
[06:12:30] <sm-msk> elliot: i'll go one step further and say that this should be a BCP; "c" stands for "current", so not too worried about mike's concern
[06:13:16] <pigdog> dave:
[06:13:20] <pigdog> 1. publish something now
[06:13:38] <pigdog> 3. label (info/bcp)
[06:13:43] <pigdog> 2. (components)
[06:14:43] <pigdog> dave: there is all kind of ops stuff in there
[06:15:00] <pigdog> dave agrees with mike about making ops statements before we get implementation experience
[06:15:06] <pigdog> tony:
[06:15:20] <pigdog> nobody has said anything against publishing something sooner
[06:15:38] <dcrocker> "you don't know if a signature is valid" is another statement that is being made periodically that I do not understand. If a signature validates, it is valid. If it doesn't, you know it doesn't.
[06:16:08] --- msj has left
[06:16:14] --- Michael Kirkham has joined
[06:16:50] <sm-msk> votes from the jabber?
[06:17:37] <thomasm> I agree with Eric
[06:19:16] <pigdog> jim fenton:
[06:19:44] <pigdog> concerned about having RFC #s behind informational docs
[06:20:36] <pigdog> dave crocker: anyone can publish anything
[06:20:54] <pigdog> the real question is whether we want to spend time driving wg consensus on a wg doc?
[06:21:01] <thomasm> mic: I'm concerned about people not thinking -base is done because -overview isn't published
[06:21:22] <dcrocker> thomas- good point
[06:21:58] <sm-msk> arvel is next on VBR
[06:22:18] <pigdog> ROUGH consensus to move forward with tony's proposal
[06:22:21] <kjetilho> dcrocker: if you haven't implemented the algorithm, you can only verify the signature's selector's existence, not the signature's validity
[06:22:48] <pigdog> arvel: we need more input on vouch by reference
[06:22:57] <pigdog> we intend to submit as informational
[06:23:19] --- shpark has left
[06:24:01] --- abelyang has left
[06:24:04] <pigdog> murray now coming to the mike
[06:24:33] <pigdog> auth results header. should we move it forward?
[06:25:38] <pigdog> stephen: reasonable
[06:25:52] <pigdog> this group should at least have a look at it.
[06:26:14] <pigdog> send pointer to the list
[06:26:19] <pigdog> we're done
[06:26:25] --- ajsaf@jabber.org has left
[06:26:25] <pigdog> bye everyone
[06:26:26] <thomasm> good night
[06:26:33] --- pigdog has left
[06:26:37] --- shpark has joined
[06:26:37] --- geoff has left
[06:26:57] <sm-msk> cheers
[06:26:58] --- Dave Cridland has left
[06:27:04] --- dcrocker has left
[06:27:04] --- randy has left
[06:27:06] --- sm-msk has left
[06:27:09] --- shpark has left
[06:27:11] --- eric has left
[06:27:13] --- fenton has left
[06:27:15] --- aaronstone has left
[06:27:20] --- Michael Kirkham has left
[06:27:28] --- raeburn@mit.edu has left
[06:27:31] --- onakayu has left
[06:27:41] --- menno has left
[06:27:56] --- barryleiba has left
[06:27:57] --- barryleiba has joined
[06:28:22] --- Stephen Farrell has left: Computer went to sleep
[06:28:38] --- cnewman@jabber.org has left
[06:30:20] --- thomasm has left
[06:32:37] --- barryleiba has left
[06:38:56] --- kjetilho has left
[06:39:11] --- tim.polk has left
[06:44:36] --- tonyhansen has left
[06:50:45] --- healthyao has joined
[06:51:18] --- healthyao has left
[06:58:55] --- fujiwara has left
[07:15:36] --- Jelte has left
[07:57:37] --- msj has joined
[08:01:06] --- msj has left
[08:02:41] --- dcrocker has joined
[08:08:52] --- hallam has left
[08:08:52] --- hallam has joined
[08:49:32] --- joonhyung.lim has left
[09:11:51] --- joonhyung.lim has joined
[09:45:36] --- joonhyung.lim has left
[10:42:12] --- LOGGING STARTED
[10:43:34] --- frank has joined
[10:43:46] --- frank has left
[10:47:34] --- dcrocker has joined
[10:48:37] --- dcrocker has left: Replaced by new connection
[10:48:38] --- dcrocker has joined
[11:31:41] --- joonhyung.lim has joined
[11:58:29] --- dcrocker has left
[11:59:03] --- dcrocker has joined
[12:02:54] --- dcrocker has left: Replaced by new connection
[12:02:55] --- dcrocker has joined
[12:09:35] --- dcrocker has left: Replaced by new connection
[12:09:36] --- dcrocker has joined
[12:17:11] --- dcrocker has left
[13:01:48] --- dcrocker has joined
[13:02:08] --- dcrocker has left
[13:02:13] --- dcrocker has joined
[13:02:21] --- dcrocker has left
[13:28:26] --- dcrocker has joined
[13:28:36] --- dcrocker has left
[13:29:29] --- dcrocker has joined
[13:32:36] --- dcrocker has left
[14:27:47] --- joonhyung.lim has left
[19:50:58] --- dcrocker has joined
[19:51:36] --- dcrocker has left