[10:52:34] --- kmurchison has joined
[10:52:49] --- kmurchison has left
[13:39:36] --- alexeymelnikov has joined
[14:47:42] --- kmurchison has joined
[14:59:57] --- alexeymelnikov has left
[15:00:11] --- alexeymelnikov has joined
[15:04:18] <alexeymelnikov> Test if I can post to the chatroom: please ignore
[15:05:33] --- alexeymelnikov has left
[15:05:38] --- alexeymelnikov has joined
[15:34:40] --- rjs3 has joined
[15:34:42] --- mrose has joined
[15:42:17] <mrose> i'm remote ... is there a scribe?
[15:42:45] --- ietf has joined
[15:43:10] <rjs3> it would be better if it was not me, but I can try
[15:43:20] <rjs3> added "private use" to saslprep discussion
[15:43:29] <rjs3> chairs review last calls since last time
[15:43:42] <rjs3> alexey has agreed to edit GSSAPI
[15:44:01] <alexeymelnikov> I would rather have somebody but Rob. He has to present/proxy
[15:44:12] --- jhutz has joined
[15:44:15] <rjs3> it looks like jeff may be joining
[15:44:16] <rjs3> ah there he is
[15:44:49] <jhutz> damn; I knew I shouldn't have sat where rob could see my screen
[15:44:51] --- ietf is now known as hartmans
[15:45:06] <rjs3> ah, so thats why you wanted me further forward
[15:45:12] <jhutz> :-)
[15:45:33] <jhutz> I'm not sure where we are, though...
[15:46:03] <rjs3> adding examples to plain: lack of initial response, failure of initial response
[15:46:12] <jhutz> OK; we're apparently still on "working group status"
[15:46:28] --- lha has joined
[15:46:34] <jhutz> hej, love
[15:46:47] <lha> hi jeff
[15:47:21] <jhutz> Sob Siemborski, presenting for Alexey on removing security layers on reauth
[15:48:04] <alexeymelnikov> Status report on DIGEST-MD5: I did a revision with AES cipher that fixes CBC mode attack. I've missed the submission deadline. I've sent new revision to Rob, Chris and couple other people, but got no comments so far
[15:48:49] <jhutz> [ rob is trying to describe the attack related to removing/replacing security layers]
[15:49:51] <alexeymelnikov> Is Rob successful :-)?
[15:50:20] <jhutz> Kurt (speaking not as chair): That's an accurate description. In my view, what we have here is a distributed server implementation. There is an implied trust relationship between the components, and the risk of the attack is a part of that trustr relation ship. I don't believe that risk justifies changing the base protocol spec.
[15:50:26] <jhutz> rjs3: I'd tend to agree with that
[15:50:55] <jhutz> Kurt: quick poll on whether to change the base spec vs security considerations
[15:51:04] <jhutz> kurt: sense of the room is to deal as a security consideration
[15:51:30] <jhutz> Rob: 2nd issue raised recently: we should consider adding text such that clients, after establishing a security layer, should check that they were not subject to a Mit
[15:51:44] <alexeymelnikov> I would like to know how many people are "against change" versa "for the change"
[15:51:50] <jhutz> MitM attack which caused negotiation away from a stronger layer
[15:52:06] <jhutz> Alexey: I don't know (I couldn't see the room), but I'll comment. FWIW, I'm against.
[15:52:08] <alexeymelnikov> Doesn't have to be exact number,I just want to have a feel
[15:52:30] --- leg has joined
[15:52:56] <alexeymelnikov> Jeff: do you understand the attack ;-)?
[15:53:38] <jhutz> There were two questions; support for change vs support for a security consideration. There were basically no hands for the first, vs ~20 for the second. Sam has just brought up your compromise [...]
[15:54:04] <jhutz> which if I understand it allows the app profile to specify whether or not an existing security layer is removed after reauth without selection of a security layer.
[15:54:33] <alexeymelnikov> Correct. The existing text should affect only LDAP
[15:54:35] <jhutz> I'm not entirely sure I do; I couldn't see an attack before but I don't think I've read your comments in the last 24 hours.
[15:56:02] <jhutz> Kurt: would prefer to keep the current behaviour, but believes that making this a profile parameter would be worse than either of the fixed alternatives.
[15:56:21] <jhutz> rjs3 concurs; adding more complexity to the framework would be problematic
[15:57:20] <alexeymelnikov> Fine, I give up. But if I don't want people to say that SASL is broken because of this and TLS is not
[15:57:55] --- kmurchison has left: Disconnected
[15:58:33] <jhutz> Sam (as chair): what I see now: we have a choice between the 2322 behaviour, which is clearly interoperable and has better security properties in situations not involving the distributed server model, vs alexey's change, which he tried to summarize but I'm having a hard time keeping up. ...
[15:58:51] <jhutz> Sam (as chair): I don't think we have concensus to change the spec at this time.
[15:59:04] <jhutz> [but I want to relay alexey's comments to the room before we move on]
[16:00:10] <jhutz> Sam will take this to the list, indicate the chairs' position, and do a concensus call
[16:01:37] <jhutz> Moving on to the full stop discussion
[16:02:57] <rjs3> >Is Rob successful :-)? < I hope I was. Sam atleast implied that he understood the attack and didn't complain ;)
[16:03:29] <jhutz> speaking now, Ienup Sung, Sun Microsystems, talking about full stop
[16:06:16] <leg> this person knows more about this than i ever will. i agree with whatever he proposes.
[16:07:03] <alexeymelnikov> Somebody has to tell me *what* he proposes
[16:07:07] <jhutz> heh. he makes a well-reasoned argument, but I believe he's wrong in this case.
[16:07:30] <jhutz> The gist of Ienup's argument is something like this (I've been talking to him about this all week)...
[16:07:30] <rjs3> ==leg
[16:07:31] <alexeymelnikov> Stop teasing me, people :-)
[16:07:43] <leg> he says that U+3002 and U+FF61 are not equivalent to U+002E.
[16:08:23] <leg> so it sounds like he believes that nameprep dropped the ball on this one; nameprep does map them to the same character, yes?
[16:08:27] <jhutz> There are 4 dot-like characters in unicode: U+002E (ASCII full stop), U+FF0E (full-width full stop), U+3002 (ideographic full stop), U+FF61 (full-width ideographic full stop)
[16:08:37] <jhutz> nameprep maps them all to the same characters
[16:09:04] <jhutz> SASLprep presently does not. It maps the full-width versions to their non-full-width equivalents, because NFKC does that, but ti doesn't map ieographic full stop to full stop.
[16:09:43] <jhutz> What ineup is trying to do right now, is educate people on the difference between these characters. Effectively they're not semantically equivalent.
[16:10:05] --- tonyhansen has joined
[16:10:25] <leg> he is now showing an xterm with lots of squiggly lines on it. it's very persuasive.
[16:10:37] <rjs3> actually, this is quite helpful to those of us hopeless americans
[16:10:38] <jhutz> He doesn't think IDN dropped the ball. My understanding is he believes that nameprep does the _right_ thing for DNS, but that we shouldn't do the same thing for the non-DNS usename and password contexts to which SASLprep applies.
[16:10:58] <leg> yes, he did just say that. i misinterpreted.
[16:12:53] <jhutz> OK. I asked ienup to clarify. His position is that SASLprep _should not_ fold ideographic full stops to U+002E, but that such mapping _should_ be done on domain names, presumably before applying SASLprep
[16:18:34] <rjs3> ienup just gave a good english language example: () vs []
[16:19:13] --- leg has left
[16:19:13] --- leg has joined
[16:19:25] <jhutz> (test)
[16:22:34] <jhutz> Sam (as chair) we need to take this to the list
[16:22:44] <jhutz> Kurt: next topic: private use characters
[16:22:56] <jhutz> the current SASLprep prohibits private-use-area characters in its output
[16:24:06] <jhutz> Jeff Altman has proposed that we move the restriction, and replace it with a note indicating [IIRC -jhutz] that such use is non-portable and should be avoided
[16:24:36] --- warlord has joined
[16:24:39] <leg> the previous discussion was interesting. this one just feels dumb.
[16:25:26] <alexeymelnikov> I see no point in allowing private use characters in public usernames/passwords
[16:25:43] <leg> will they be allowed in e-mail localparts?
[16:25:52] <jhutz> Jeff gives two justifications for using private-use characters: experimentation, and support for private characters with local meaning within some companies and organizations, particularly within Japan.
[16:26:07] <jhutz> Alexey: I'd argue that passwords are not supposed to be public :-)
[16:26:36] <leg> i see no reason to prohibit them. let people hang themselves.
[16:26:38] <jhutz> Ienup is making another argument. He believes that even though such characters won't be interoperable between sites, some sites will have a strong desire to use them internally.
[16:26:59] <alexeymelnikov> Sure ;), but not all clients will allow to enter them.
[16:27:00] <jhutz> ==leg; I think we should let people hang themselves if they want.
[16:27:41] <alexeymelnikov> How widespread is usage of private range?
[16:27:50] <rjs3> apparently pretty wide in japan
[16:27:54] <jhutz> Kurt (as participant?): We can't just remove the prohibition; if we remove it, we need to specify bounds on how they can be used; normalization, bidi checking, etc
[16:28:47] <alexeymelnikov> Is there a convention in Japan, or every company in Japan chooses to do something different?
[16:28:47] <jhutz> FWIW, the so-called "private use" range actually has an unofficial but widely-recognized registry, and there are some widely-used characters
[16:29:13] <alexeymelnikov> Jeff: in this case it is not really "private"
[16:29:29] <jhutz> You got it!
[16:29:43] <alexeymelnikov> It seems that people just have problems dealing with Unicode Consortium
[16:30:04] <jhutz> though apparently not all of the range is registered in this fashion; some really do have local scope and different meaning in different places
[16:30:50] <jhutz> every company in japan does do something different. but there are conventions for things like Klingon, or taiwanese characters that the mainland chinese government won't let into the official unicode spec
[16:31:20] <jhutz> Sam (as chair): it doesn't sound like we have a clear concensus here; taking it to the list
[16:31:30] <leg> "most software doesn't allow private use characters" --- i can't believe that's true. i bet most software on windows allows private use characters.
[16:31:46] <jhutz> next speaker: Rob Siemborski, on SMTP AUTH
[16:32:05] <alexeymelnikov> Larry: I can easily test this
[16:32:09] <jhutz> oh; this is the initial-response issue
[16:32:14] <jhutz> SLIDE: background:
[16:32:29] <jhutz> - proposal to add initial response to imap (draft-siemborski-imap-sasl-initial-response-00.txt)
[16:32:42] <jhutz> - Issues raised about initial response implementation quality in POP3 and SMTP:
[16:32:55] <jhutz> -- servers that require initial response argument
[16:33:10] <jhutz> -- servers that fail to issue empty initial challenge
[16:33:14] <jhutz> - [missed third point]
[16:33:20] <jhutz> SLIDE: issues raised on list:
[16:33:34] <jhutz> - new pop3/smtp drafts issued: draft-siemborski-rfc{2554,1734}bis-00.txt
[16:33:45] <jhutz> - some implementors fail to read all referenced documents
[16:33:57] <jhutz> - documents should have clearer examples that cover more use cases
[16:34:15] <jhutz> (the issue here is that implementors don't read SASL + the app profile + the mech profiles; they assume one is enough)
[16:34:21] <jhutz> SLIDE: proposals and concensus:
[16:34:25] <jhutz> - draft-ietf-sasl-plaint:
[16:34:38] <jhutz> -- recommendation to change examples from ACAP to SMTP (mailing list concensus against change)
[16:36:04] --- kmurchison has joined
[16:37:28] <jhutz> -- add an example where the client omits the initial response argument (kurt agreed)
[16:37:28] <jhutz> - draft-ietf-sasl-rfc2222bis:
[16:37:28] <jhutz> -- clarifications in section 6.1 and an addition of client-send-first example (alexey said he would be working on this in next draft)
[16:42:31] --- lha has left
[16:43:16] --- rjs3 has left
[16:43:26] --- hartmans has left
[16:43:41] <jhutz> conclusion
[16:43:44] <jhutz> bye
[16:43:47] --- jhutz has left
[16:43:49] --- kmurchison has left
[16:45:27] --- alexeymelnikov has left
[16:46:59] --- tonyhansen has left
[16:50:18] --- warlord has left
[16:54:29] --- leg has left: Disconnected
[17:44:25] --- mrose has left