[14:31:29] --- jlcjohn has joined
[14:48:15] --- mtnviewmark has joined
[14:49:09] --- andy has joined
[14:49:28] <andy> hello all
[14:49:37] <mtnviewmark> hello
[14:50:03] <jlcjohn> looks like a capacity crowd today...
[14:50:04] <andy> I guess we should wait a bit to see if more people come along.
[14:55:55] --- mrose has joined
[14:57:44] <mrose> sorry, i'm late
[14:58:07] <mtnviewmark> boy, now we're gonna have to rehash soooooo much!
[14:58:39] <andy> So, do you guys want to proceed?
[14:58:51] <mtnviewmark> sure, what's on the plate?
[14:59:33] <jlcjohn> not much on mine -- I think we're all waiting on I-D updates...
[14:59:48] <andy> Well, we figured it was now time to talk about CSV (some more).
[15:00:03] <mtnviewmark> my I-D is almost there, I'm waiting on some input from the DNS folks
[15:00:16] <jlcjohn> be happy to (talk about CSV)
[15:00:54] <andy> And I know a couple of people mentioned they were holding off on CSV criticisms until the such time as they thought full CSV discussion was open. So, it is now "open season".
[15:01:16] <jlcjohn> (Mark was one, as I recall...)
[15:01:22] <mtnviewmark> well, yes
[15:01:25] <andy> I'm sure John doesn't have much bad to say about CSV, so Mark?
[15:01:58] <mtnviewmark> well, let's not assume what I'm saying or asking is bad, okay....
[15:02:03] <jlcjohn> OK
[15:02:14] <andy> Critique?
[15:02:25] <mtnviewmark> I'd like to understand how the w=1, or "not authorized" setting is intended to be used...
[15:02:35] <mtnviewmark> ...in light of wildcards, it doesn't look that useful
[15:02:40] <mtnviewmark> ?
[15:02:52] <jlcjohn> Wildcards are a weak point with CSV, yes...
[15:03:27] <jlcjohn> w=1 doesn't _exactly_ mean not authorized. there are two bits
[15:03:48] <jlcjohn> w=1 actually means "ignore target IP addresses" IIRC
[15:04:13] <jlcjohn> were w=2 present; it would mean "authorized"; when it's absent,
[15:04:28] <mtnviewmark> I didn't mean the bit, I meant the value
[15:04:28] <jlcjohn> we call the case "not authorized".
[15:04:30] <jlcjohn> <eot>
[15:04:57] <jlcjohn> the value w=1 is the combination of the two, meaning that the
[15:05:14] <mtnviewmark> So, in practice, since the wildcards don't work, you'd expect domains to attach a SRV record to every name not used in HELO with w=1?
[15:05:28] <jlcjohn> target list should be ignored, and don't worry about finding authentication some other way, because it's not authorized anyway.
[15:05:57] <jlcjohn> we don't expect to see this a lot -- certainly not _every_ domain...
[15:06:10] <jlcjohn> <eot>
[15:06:30] <mtnviewmark> so, do when then expect the absence of a CSV SRV record to eventually be taken as a de facto non authorized?
[15:06:42] <mtnviewmark> <eot>
[15:07:08] <jlcjohn> No, actually we don't expect to attach the absence of "authorization" as meaning much.
[15:07:44] <mtnviewmark> So, there isn't a practical way to "not authorize" with CSV, which is okay w/me, I'm just trying to understand what the point of w=1 is
[15:07:47] <mtnviewmark> /eotc
[15:08:05] <jlcjohn> 'tis true.
[15:08:47] <jlcjohn> the "point" of w=1 is mostly to avoid traffic by broken resolvers against the root, if people use the "." convention.
[15:08:50] <jlcjohn> <eot>
[15:09:16] <mtnviewmark> you mean broken implementations?
[15:09:20] <jlcjohn> yes
[15:09:33] <mtnviewmark> sees a little paranoid...
[15:09:44] <andy> Is there an issue with adoption then? Do you see CSV as having to be widely adopted before "authorization" becomes meaningful? Currently with SPF, I only pay attention to the "DENY" and treat "PASS" or anything else like I did before the days of SPF. Is this similar?
[15:09:49] <jlcjohn> Vixie, I think it was, complained that this broken traffic was great enough to be a problem.
[15:10:33] <jlcjohn> The authors do not see any problem of implementation needing to wait for extensive record publication.
[15:10:37] <andy> Are you expecting an SRV in the root?
[15:11:22] <jlcjohn> Andy: no -- not expecting it, just expecting broken records with broken implementations of resolvers; and trying to minimize collateral damage.
[15:11:50] <andy> I'm confused. Can you explain this further?
[15:11:52] <jlcjohn> specifically, we never attach any meaning to subdomains when a given level domain is advertised
[15:12:52] <jlcjohn> Andy: the brokenness is that some implementations, when trying to serve a SRV reply, actually _do_ the lookup against ".", which is the root
[15:13:16] <jlcjohn> Personally, I don't understand _why_ this is a significant problem.
[15:13:19] <mtnviewmark> and so w=1 is there so root can serve a record with it?
[15:13:25] <jlcjohn> But I'm willing to believe it is.
[15:13:29] <jlcjohn> <eot>
[15:14:16] <jlcjohn> Mark: w=1 is intended to stop CSV implementers from attempting to resolve whatever may be in the target field.
[15:14:42] <andy> Ah.
[15:14:43] <mtnviewmark> but who would publish such a record?
[15:14:50] <jlcjohn> The request we received was to specify something _other_ than "."
[15:15:11] <jlcjohn> The actual SRV RFC calls for using ".
[15:15:23] <jlcjohn> " in the case where an empty list is intended.
[15:15:41] <jlcjohn> So... anyone literally following the RFC would do so.
[15:15:44] <jlcjohn> <eot>
[15:15:56] <mtnviewmark> right - but you only publish an empty list to mean "not authorized", yes?
[15:16:12] <jlcjohn> Actually, that's not entirely true.
[15:16:18] <mtnviewmark> ?
[15:16:41] <jlcjohn> There are cases where the list of Address records would be too long, and the DNS server is set up to return partial lists.
[15:17:03] <jlcjohn> Partial lists are _not_ helpful to us, of course.
[15:17:28] <mtnviewmark> so, in essence, there is no practical case for w=1?
[15:17:32] <jlcjohn> So, we intend that there be a way to say, "Don't depend upon Address records for authentication."
[15:17:35] <jlcjohn> <eot>
[15:17:46] <mtnviewmark> I thought that was w=3
[15:17:53] <mtnviewmark> /eot
[15:18:19] <jlcjohn> Mark: I wouldn't go so far as to say _no_ practical use for w=1, but it is _not_ intended to be common.
[15:18:52] <jlcjohn> w=3 is the more normal case -- still rare, we hope, but known to exist in the wild, and worth describing.
[15:18:55] <jlcjohn> <eot>
[15:19:39] <andy> So what type of authentication does occur if w=3?
[15:19:42] <mtnviewmark> well, certainly the drafts don't give any clear practical use of w=1, w=3 or w=0... /eot
[15:20:21] <jlcjohn> Andy: we've discussed the w=3 case, and can't reach agreement among ourselves of how to describe a useful case.
[15:20:51] <jlcjohn> Nonetheless, we all agree that there _could_ be a useful case where authentication could be otherwise "proven"
[15:20:54] <jlcjohn> <eot>
[15:21:23] <mtnviewmark> Second issue: what is the point of having the indirection through the target name if that name ends up having to be a valid hostname (due to it's A record) -- why wouldn't the host just use that name?
[15:21:41] <jlcjohn> Mark: I believe we could add some language to make the cases other than w=2 clearer; and especially to say that w=2 is the "expected" normal use.
[15:22:19] <jlcjohn> Mark, re indirection: we do not envision a normal case here.
[15:22:46] <mtnviewmark> can you construct a practical, non-normal case? /eot
[15:22:51] <jlcjohn> However, we can imagine cases where it would be useful to use a different A)ddress record, and it breaks nothing, so we allowed it.
[15:23:38] <jlcjohn> Dunno if I can satisfy anyone it's "practical", but there are certainly cases where a single domain name is used for all functions, but only some of them actually involve email.
[15:23:41] <jlcjohn> <eot>
[15:23:58] <mtnviewmark> hmmmm
[15:24:04] <jlcjohn> exactly!
[15:24:30] <jlcjohn> Understand, we're setting out to require the _absolute_ minimum of changes to existing practices.
[15:24:34] <jlcjohn> <eot>
[15:24:46] <mtnviewmark> I guess, since target almost always equals helo name, and w=2 most times....
[15:25:20] <jlcjohn> That's the only fully "normal" case, yes.
[15:25:21] <mtnviewmark> ...I'm not sure why the SRV record does any more than forward checking the HELO directly.
[15:25:24] <mtnviewmark> /eot
[15:25:46] <jlcjohn> One _critically_ important thing is to get the explicit authorization bit.
[15:26:19] <mtnviewmark> you mean a domain saying "yes, we let mail out from that server"? /eot
[15:26:31] <jlcjohn> And we're concerned about network traffic, so we consider it important to know whether the A)ddress lookup will serve for authentication.
[15:27:15] <jlcjohn> Mark, re authorization meaning: that's mostly it, but "authorized" means more than "we don't prohibit it."
[15:27:21] <mtnviewmark> well, the A check on HELO is one less RR to look up, since CSV's SRV record must come with that same A RR
[15:28:01] <jlcjohn> Actually, the SRV lookup is a more limited case (for network traffic) than the A)ddress lookup.
[15:28:31] <jlcjohn> Granted, it may return less information, but we don't see that as an issue.
[15:28:34] <mtnviewmark> because you are worried about ascribing reputation to a name a domain controls without the domain saying we control it?
[15:29:18] <jlcjohn> Mark, re reputation: Yes, we're _quite_ concerned about matching reputation information to actual declared intent by the domain.
[15:29:24] <mtnviewmark> can you explain how it is less traffic?
[15:30:02] <jlcjohn> Mark: re traffic. The SRV response _will_ fit in one UDP query -- the A)ddress response may not.
[15:30:31] <jlcjohn> (I meant "packet" of course.)
[15:30:33] <mtnviewmark> but but, you say everywhere the A records will fit and come in the same response!
[15:30:55] <mtnviewmark> And you need them to do the authorization
[15:31:04] <mtnviewmark> er, authentication
[15:31:18] <jlcjohn> No, actually we're careful to say A RRs "may" be returned: if you can find a case where we say "will", I'd like to fix it.
[15:32:04] <mtnviewmark> but the server needs to fetch the A records anyway....
[15:32:10] <mtnviewmark> ...so no savings
[15:32:21] <jlcjohn> Mark, re authentication: we recognize that authentication by a single mechanism that breaks no existing practices is not always possible.
[15:33:13] <jlcjohn> Mark, re needs to fetch: I don't follow you. In the ordinary case, the domain publishing the SRV record will arrrange things so they do.
[15:33:17] <mtnviewmark> and under what normal conditions do you expect the A records for a HELO domain not to fit in a UDP packet?
[15:33:58] <jlcjohn> In exceptional cases, the A)ddress query may be needed, but the additional load is relatively minor, and we explicitly say that it may be bypassed based upon a reputation query.
[15:34:02] <jlcjohn> <eot>
[15:34:06] <mtnviewmark> My point is that doing an A lookup on the HELO domain results in some A records; whereas the CSV check requires getting the SRV records and the same A records -- more info
[15:34:58] <mtnviewmark> But ditto - a reputation query might obviate the A record fetches too.... -- though I don't see how unless you pass the IP to the reputation service and they know all the IPs for the domain
[15:35:22] <jlcjohn> Mark: re overhead of SRV: yes, there is overhead. We see it as minor, and in the cases where it might break the UDP packet limit, we're likely not to care that much about retrieving the info.
[15:36:20] <jlcjohn> Mark: re reputation report: It's unlikely that reputation services will find the case to be common enough to report; but they certainly _could_ collect the "complete" list of IP addresses, and report it out of band.
[15:36:27] <mtnviewmark> I'm not really worried about the overhead. I'm just noting that other than the explict "bit o' authroization" from the domain, the CSV scheme is essentially an A record lookup on the HELO domain to match the IP of the client.
[15:36:52] <mtnviewmark> ...Which is I believe already current practice available in some MTAs
[15:37:10] <jlcjohn> Mark, re essence of CSV: We see it quite the other way: that the essence of CSV is that authorized bit.
[15:37:32] <jlcjohn> I don't disagree that your way of looking at it makes sense...
[15:37:33] <mtnviewmark> Good, I'm glad I now understand that -- it isn't clear at all from the drafts.
[15:37:51] <jlcjohn> Can you suggest specific places to improve the clarity?
[15:38:07] <mtnviewmark> So, since there is an existing way to do all the rest of it, and it is coded, and running in MTAs, and current practice -- perhaps we should be getting that "bit" another way...
[15:38:24] <mtnviewmark> Or rather, perhaps CSV shouldn't conflict with all that.
[15:38:42] <jlcjohn> Mark: re getting bit another way: I definitely expect WG discussion about that.
[15:39:06] <jlcjohn> Mark, re "conflict": I really don't see a conflict
[15:39:39] <jlcjohn> CSV is about authentication, authorization, and reputation; and is intended to refer to the channel.
[15:39:41] <andy> re getting the bit another way: I believe Exim currently does the A record lookup and I know people are working on patches for Courier. I wouldn't be surprised if there was a qmail patch for it already.
[15:39:50] <mtnviewmark> well, there is a bit because of the target indirection
[15:39:59] <jlcjohn> All the various SPF flavors are concerned about individual messages.
[15:40:17] <mtnviewmark> Postfix, I believe does the A check if you want (it will also so a rDNS check if desired)
[15:40:33] <andy> re conflict: It seems to me that if an MTA already does forward A that doing CSV would have to deprecate that practice.
[15:40:40] <mrose> time to start wrapping it up
[15:40:55] <jlcjohn> Certainly the A)ddress query is coded into some MTA software; but
[15:41:12] <jlcjohn> does not recognize the cases where A)ddress authentication breaks.
[15:41:27] <jlcjohn> I don't follow how this has anything to do with "authorization".
[15:41:30] <jlcjohn> <eot>
[15:41:42] <mtnviewmark> sure it does, if the A query doesn't match, the connection is rejected.
[15:41:58] <mtnviewmark> meaning, not authorized -- which admittadly is pushing 2821 a bit...
[15:42:13] <jlcjohn> Andy: re deprecate: I see no reason to "deprecate": we could mention the redunancy...
[15:42:53] <jlcjohn> Mark: re rejection for A)ddress failure: I consider this unfortunate, but somewhat out of scope for CSV.
[15:43:05] <andy> However, I do see the CSV point that an A may exist for other reasons, that doesn't necessarily mean it is suppose to be an outbound MTA.
[15:43:17] <mtnviewmark> Only, that is exactly what CSV would do, if the "bit o' authorization" were there.
[15:43:21] <jlcjohn> We certainly don't _recommend_ that practice; but it does serve to call people's attention to misconfigurations of EHLO.
[15:43:48] <jlcjohn> Mark: I don't understand "what CSV would do"...
[15:44:29] <mtnviewmark> If I do a CSV query, get back w=2, get a target, get the A records of the target, and the client IP isn't in that list -- don't I reject the connection as it isn't authenticated?
[15:44:52] <jlcjohn> Mark: essentially yes.
[15:45:27] <jlcjohn> (Actually, you return an error saying "authorization failed" or words to that effect.
[15:45:27] <mtnviewmark> which is what current MTAs do if that feature is turned on, again, modulo that they don't have a "bit of authentication" to rely on
[15:46:40] <mtnviewmark> okay - well, I need to go soon too
[15:46:53] <jlcjohn> Let's be clear: CSV would reject in the case Mark listed because the sending MTA's domain claimed to release a full list of "authorized" MTAs and the one we're talking to isn't on it.
[15:47:02] <mtnviewmark> yup
[15:47:05] <andy> Ok. Thanks.
[15:47:06] <jlcjohn> Actually, I even more need to go soon...
[15:47:19] <andy> This has been good. Let's see if this can be continued on the list?
[15:47:28] <mtnviewmark> thanks for clearing up some foggy points for me
[15:47:31] <jlcjohn> Shall we declare victory, and post some summary to the list?
[15:47:44] <mtnviewmark> victory? was there a battle?
[15:48:00] <andy> Just a summary will do. Thanks.
[15:48:03] <mtnviewmark> I'll be pretty busy with the drafts this week - I'll be able to engage more next week.
[15:48:08] <jlcjohn> In the sense of "attacking the darkness", certainly. ;^)
[15:48:16] <mtnviewmark> yes! bye
[15:48:19] <jlcjohn> Thx
[15:48:21] <andy> bye
[15:48:22] --- mtnviewmark has left: Disconnected
[15:48:24] <mrose> bye
[15:48:28] --- mrose has left
[15:48:28] --- andy has left
[16:22:11] --- mtnviewmark has joined
[16:23:41] --- mtnviewmark has left: Disconnected
[16:25:29] --- mengwong has joined
[16:29:21] --- mengwong has left: Disconnected
[21:12:32] --- tonyhansen has joined
[21:12:52] --- tonyhansen has left