[14:07:09] David.Cooper joins the room [14:11:51] mlclm joins the room [14:21:16] alexey.melnikov joins the room [14:21:28] alexey.melnikov leaves the room [14:23:27] jimsch joins the room [14:23:43] hartmans@jis.mit.edu/owl joins the room [14:23:56] ietf-meeting joins the room [14:24:07] jhutz joins the room [14:24:11] jlcjohn joins the room [14:24:56] nico joins the room [14:27:44] Chris Newman joins the room [14:28:52] rlbob joins the room [14:29:36] so [14:30:17] so? [14:30:25] EronenP joins the room [14:30:31] whee! [14:31:04] ah [14:31:08] the room works now [14:32:19] mrex joins the room [14:32:54] nico has dropped the ball on scram [14:35:31] gs2 as informational? [14:37:06] lynch joins the room [14:38:08] ? Why would we want to do gs2 as informational? [14:38:44] huh? I don't think anyone has suggested gs2 as informational. We're talking about CRAM-MD5 [14:39:21] I'm following the audio and confused [14:39:36] David.Cooper leaves the room [14:39:38] excuse me [14:44:10] David.Cooper joins the room [14:45:30] nico agrees with Sam's statements about channel binding [14:46:17] mlclm leaves the room [14:46:18] in fact, I would make a stronger statement [14:46:32] polk.tim joins the room [14:47:06] if the mechanism has no sec layers, or the client didn't want any sec layers, AND the client did channel binding, and channel binding failed, then the mechanism MUST fail authentication on BOTH sides [14:48:06] Sam: simplify, if you believe you've verified the server's cert, and that the issuer is not MITMing you [14:48:19] then don't bother with channel binding [14:48:30] the channel binding then is implicit in the choice of server names at both layers [14:49:42] this belongs on the list anyways [14:49:53] how long can we talk about this in this meeting? [14:51:30] nico agrees with Chris Newman [14:51:32] Does GS2 actually get this right in the non-sec-layer case? [14:51:40] sam: dunnop [14:51:48] at the API level, ignoring the channel bindings when they don't match seems like a bad idea [14:51:58] is the jabber room displayed in the physical room? [14:52:05] yes [14:52:14] The jabber room is displayed, yes. [14:54:03] I second Kurt on that. Sign everything. [14:54:27] I don't think unrecognized attributes should be allowed. We can always create a new mechanism name if we need new attributes. [14:54:28] if someone wants to do some kind of "intrusion detection", i.e. some sort of heuristics trying to recognize attacks, that should be seperate from API parameters that go into the authentication [14:55:33] tlyu@jis.mit.edu joins the room [14:57:22] well [14:57:43] typically there's a need for critical extensions whenever we have a need for extensions [14:58:11] usually there's a need for some non-critical extensions [14:58:31] no extensions is fine [14:58:33] critical for whom (server or client)? [14:58:48] but do leave yourselves room to add some extensions [14:58:56] for clients you might want primarily optional extensions, to improve interop [14:59:04] mrex: critical for both [14:59:13] for servers, one might want critical extensions, to implement specific policies [14:59:24] well, no, make sure there's room for a *single* critical extension [14:59:53] I dislike "need for extensions" questions... [14:59:54] the spec need only say "the client MUST send 0 in this field and the server MUST blah blah if it isn't" [15:00:24] right. [15:00:41] thanks jhutz -- that's exactly right, if you say "no extensions" then that's what that means [15:00:58] not exactly... [15:01:11] folks, ensuring there's a hole in which to shove critical extensions is easy [15:01:14] we do this all the time [15:01:23] there's no need for an extended debate on the topic [15:01:43] jlcjohn: well, it's what it *should* mean [15:01:59] yes [15:01:59] :^) [15:02:02] blah blah -> fail [15:02:53] or blah blah -> server tells client that it ignored the extension [15:03:11] the latter allows the client to decide whether it's happy [15:03:42] oh, duh, SCRAM is a keyword=value ABNF [15:03:53] seperate the namespace for keywords in critical and non-critical keywords [15:03:59] so, yes, what Sam suffices [15:04:39] like keywords that start with "CRITICAL-" are critical, others are non-critical and ignored [15:05:51] kurt: hard to say whether I will care someday [15:06:52] i suggest keeping it simple: no extensions. if extensions prove to be needed later, do SCRAM2. [15:07:11] the *easy* solution is to negotiate by the mech name [15:08:02] rlbob: true, if we do hash negotiation by mech name, then you might as well do the same for critical extensions [15:08:11] (hash negotiation is a critical extension of sorts) [15:09:03] yes, I'd forgotten about that too [15:09:42] negotiating mechs based on username leaks info [15:10:11] i c [15:11:48] yeah, you can choose to not leak, by lying. [15:12:05] It's all pretty elegant. Though I don't remember how much of it was my idea, if any. [15:12:15] in which case you're back to the original problem [15:12:16] but, hey [15:12:32] as long as the server gets to choose, that's fine [15:12:52] the server would choose not to lie only for the duration of a hash transition [15:13:38] where are the slides :) [15:14:34] ietf-vnc.central.org [15:14:41] also... [15:14:53] https://datatracker.ietf.org/meeting/72/materials.html#wg-sasl [15:15:15] But if you use VNC, we can point the mouse at things. [15:16:36] imagine that, me making a mistake :) [15:19:23] we rejected realms [15:19:50] it was my proposal, but the point was made that noone actually uses it [15:20:36] the idea was to make it possible to share different verifiers with different servers, but all for the same-user@same-domain [15:20:47] I don' [15:20:57] t care if the feature is in if noone would use it [15:21:09] don't recall if it was rejected on the list [15:22:43] lynch leaves the room: Replaced by new connection [15:22:43] lynch joins the room [15:22:52] it should require no protocol extensions to LDAP [15:23:13] let SCRAM servers have configurable attribute names for this [15:23:48] chris: why can't the attribute be configurable? [15:24:13] I need to get back into a day job where IETF work is relevant [15:24:18] :) [15:24:22] so I can be in the room [15:24:34] :) [15:24:40] yes, you do [15:24:53] alternatively stop participating all together [15:25:02] no no no [15:25:16] I need to find funding for IETf too:-) [15:25:34] bake sale time [15:27:32] David.Cooper leaves the room [15:29:21] then /me dropped the ball [15:29:30] sadly [15:29:42] David.Cooper joins the room [15:29:50] you need context to eval the notes [15:30:01] the notes are just ABNF w some comments [15:32:06] two different specs for the same thing is dangerous -- one should be normative, and implementors following the other should be cautioned to interop test with implementors of the normative version [15:32:14] but that seems likely to be controversial too [15:32:40] proving that the two specs are equivalent would be nice, but difficult [15:34:27] I believe people who write international treaties have this problem all the time. [15:34:55] SE-STEFANS-TTV joins the room [15:35:15] SE-STEFANS-TTV leaves the room [15:35:24] stefans joins the room [15:35:59] lynch leaves the room [15:36:48] jhutz: yes, that's true, but there the solution is less rigorous than it needs to be here [15:38:12] Maybe [15:39:03] treaties usually have processes involved w.r.t. settling differences in interpretation [15:39:15] the ultimate such process is called war [15:39:21] :/ [15:39:31] I was going to say, the process is biggest-guns-win [15:45:10] I think we need an indication that the client is using channel binding via the cnonce, and maybe the channel binding type needs to be separate, but I don't think the channel binding data itself needs to appear twice (once in the cnonce and once in the channel-binding parameter [15:45:43] this has shipped? [15:45:55] are there XMLHttpRequest extensions for this? [15:46:30] XMLHttpRequest is practically a standard, so any extensions to it for this should be included in the spec [15:46:37] Ask Larry [15:47:02] is Larry in the room? [15:47:12] yes [15:47:27] JavaScript [15:47:37] yes, AJAX [15:47:37] kdz joins the room [15:48:17] yes [15:48:19] off-line [15:48:29] EronenP leaves the room [15:48:37] but you *really* want XMLHttpRequest to have an extension for this if you want DIGEST with channel binding to get used [15:51:57] polk.tim leaves the room [15:57:11] EronenP joins the room [16:18:26] rlbob leaves the room [16:18:52] jimsch leaves the room [16:19:16] tlyu@jis.mit.edu leaves the room [16:19:18] Chris Newman leaves the room [16:19:22] kdz leaves the room [16:22:17] David.Cooper leaves the room [16:35:17] jhutz leaves the room [16:35:40] ietf-meeting leaves the room [16:36:03] EronenP leaves the room [16:41:02] mrex leaves the room [16:44:58] stefans leaves the room [16:46:24] the audio delay must be an incentive to attend physically [16:46:27] :) [16:47:20] nico leaves the room [21:45:02] jlcjohn leaves the room