saag@conference.ietf.jabber.com - 2003/03/20
[08:45] %% logger has arrived.
[16:03] %% mrp has arrived.
[16:26] %% hartmans has arrived.
[16:28] %% jis (the lame duck) has arrived.
[16:28] %% jhutz has arrived.
[16:52] <hartmans> Kerberos met on Monday. Doug summariezes.
[16:52] <hartmans> Started working group last call on clarifications and AES. Crypto will start as soon as RFC editor posts
[16:53] <hartmans> Clarifications had one last call but is having a second one.
[16:53] <hartmans> And for anything who thinks that Kerberos is near concluding, they are basically wrong(my comment)
[16:53] %% tlyu has arrived.
[16:54] <hartmans> msec: Met Monday night. The AD was there though. Went through recharter process.
[16:54] <hartmans> Two drafts gone to last call.
[16:54] <hartmans> I can't hear this well enough to summarize
[16:54] %% mrose has arrived.
[16:55] <hartmans> smime: New chairs so AD can be AD.
[16:56] <hartmans> 11 drafts: 1 at editor, 5 at IESG, 4 going into WG last call
[16:56] <hartmans> Update required for DSS draft
[16:57] <hartmans> Ipseckey has one draft; going to last call now.
[16:58] <hartmans> Ted tells us about ipsec
[16:58] %% leg has arrived.
[17:03] %% danwing has arrived.
[17:04] %% warlord has arrived.
[17:05] <jhutz> anyone seen ka9q?
[17:05] <jhutz> or wesommer?
[17:06] <warlord> I saw ka9q during lunch
[17:08] %% shep has arrived.
[17:09] <hartmans> Which Wg is this right now?
[17:10] <jhutz> ipsp
[17:13] %% perry has arrived.
[17:14] %% ole has arrived.
[17:15] <jhutz> we've seen this before, in like atlanta or something
[17:15] <jhutz> not at saag, but at eap
[17:16] <warlord> Yes
[17:16] <warlord> we did
[17:22] <leg> is there nothing fun happening over there? you're all so quiet.
[17:22] <warlord> hearing about EAP MitM attacks
[17:23] <perry> does anyone have a brief summary of this?
[17:23] <hartmans> either warlord or I will point out SASL has the same issues once we're done listening.
[17:23] <perry> I must admit the presentation style does not assist in understanding the problem precisely.
[17:23] <jhutz> as I noted, we've heard about this before. I really hope this doesn't become the target for the open-mike flamewar, because I'd much rather have a more interesting topic
[17:23] <perry> what would you prefer we flame about?
[17:23] <perry> ah, uri is going to the mike
[17:24] <jhutz> iI don't know. something more interesting.
[17:25] <jhutz> I seem to recall that if you actually just look at the slides, the nature of the problem is pretty easy to understand. Well, it should be for you, anyway
[17:25] <warlord> perry, I'll gladly explain this to you over a beer later.
[17:25] <leg> URL for slides?
[17:25] <perry> okay.
[17:25] <warlord> leg: I dont think there is one yet.
[17:26] <hartmans> The problem may be easier to understand in SASL. If I use TLS for no authentication just confidentiality, and use sasl for authentication, I have a MITM attack
[17:27] <perry> of course
[17:27] <perry> that's obvious
[17:27] %% perry has left.
[17:27] %% perry has arrived.
[17:28] <warlord> jis is typing the URL
[17:28] <jis (the lame duck)> URL for presentation is: http://www.drizzle.com/~oboba/IETF56
[17:28] <jhutz> www.drizzle.com/~aboba/IETF56
[17:28] <warlord> look for eap binding
[17:28] <shep> http://www.drizzle.com/~aboba/IETF56/ if I typed it correctly
[17:28] <hartmans> Well, EAP has this tls tunnel
[17:28] <perry> okay...
[17:28] <hartmans> It was going to proivide encryption for weak mechanisms
[17:28] <perry> I think I'm getting it now.
[17:28] <hartmans> OK, cool.
[17:29] <jhutz> .../EAP/EAP-Binding-Problem-0303.ppt
[17:29] <perry> the presentation was a bit less direct
[17:29] <shep> http://www.drizzle.com/~aboba/IETF56/EAP/EAP-Binding-Problem-0303.ppt
[17:29] <jhutz> yes, the presentation was pretty hard to follow. it had that problem last time I saw it as well.
[17:30] <warlord> A lot of it requires deep understanding of EAP
[17:30] <jhutz> I think the problem may in part be an assumption that the audience are experts on eap but not on security.
[17:30] <warlord> Indeed, I'm sure it was written that way
[17:30] <jhutz> so we're not getting the background we need, and are getting background that we don't need and is confusing
[17:30] <warlord> Feel free to ask this.
[17:31] <leg> that presentation is particularly hard to follow.
[17:31] <leg> but obviously these class of problems are problems for certain threat models.
[17:31] <leg> and that sentence looks like a tautology.
[17:32] <warlord> heh
[17:34] <tlyu> i suspect more effort towards education may be needed...
[17:35] <jhutz> er, I guess I should point this out here....
[17:36] <jhutz> this is a multicast session. if you don't use the mic, people watching the multicast feed can't hear you
[17:37] <tlyu> perhaps we are not focusing on authorization because it is *hard*
[17:39] <ole> Security people are very strange...
[17:40] <warlord> people are strange... when you're a stranger...
[17:41] <ole> Yeah, or an alien in my case :-)
[17:43] <perry> Every disjoint set of X.509 certs is in some sense a different public key infrastructure that doesn't interoperate with the others
[17:43] <perry> if you don't have the root key for that PKI, you can't use it
[17:44] %% jakob has arrived.
[17:44] <perry> more protocols! we need metaprotocols to fix the other protocols!
[17:46] %% jakob has left.
[17:48] <hartmans> I think the reason we are not going to accept the consequences as Paul suggests is that they are unacceptable.
[17:55] %% JavierA has arrived.
[17:57] <ole> Cue Mr. Hallam-Baker
[17:57] <perry> PHB.
[17:58] %% JavierA has left.
[18:02] <jis (the lame duck)> Boy this is an old story. The problem is that the rest of the IETF wants pixie dust...
[18:03] <perry> maybe we should just give it to them. how would they know the difference? the question is, how do we get paid for defrauding them. :)
[18:06] <hartmans> And you think if you close down the working groups people are interested in, they will continue to come and to pay attention?
[18:06] <warlord> yes, they want pixie dust, but we can apply it (to an extent) if we get involved early in the process.
[18:06] <jis (the lame duck)> Late in the process: "Why didn't you get involved in the beginning?"
[18:06] <hartmans> ==warlord I think we should at least do a good job of 1) making it easy for people to know who is interested in helping 2) who needs help
[18:06] <jis (the lame duck)> Early in the process: "Go away, we'll worry about security later"
[18:07] <hartmans> I expected secdir to do that; so far it has significantly been a disappointment at least from a public standpoint
[18:07] %% rlbob has arrived.
[18:07] <hartmans> jis in many cases I've actually not found that reaction, although certainly in some I have.
[18:08] <warlord> i would agree with hartmans -- in general people have been very welcoming of early-process security clue. They don't always like the response they get....
[18:09] <hartmans> then there is provreg. . .
[18:09] <shep> hmmm.... random thought... why is secsh in the security area and not in the APP area of the IETF?
[18:09] <perry> because the security guys got to it first.
[18:09] <warlord> It's considered a secure transport protocol.
[18:09] <tlyu> people like tunneling everything over ssh? :-)
[18:09] <hartmans> and why is pana in the internet area not security? . . . There are some very strange wg designations
[18:10] <warlord> pana is one of the groups that actually accepted the security clue provided and acted on it. For example, security people caused pana to think about requirements.
[18:10] <perry> there have been many successes
[18:10] <hartmans> Does pana actually yet know what tehy are going to do?
[18:10] <warlord> And sure, there have been some failures.
[18:11] <perry> but, quoting shakespeare, "the evil that men do lives after them, the good is oft interred with their bones."
[18:11] <warlord> hartmans: they think they do. I have not verified it recently.
[18:13] <perry> bill's question is answerable
[18:13] <perry> that I know how to solve no problem.
[18:13] <jhutz> I don't think secdir is a failure by any means. I think it's just taking a while to spin up.
[18:13] <perry> years of being a consultant. ;)
[18:14] <hartmans> jhutz - I didn't say it was a failure, simply that I have been disappointed by it.
[18:15] <jhutz> I think it can do better, and hopefully will.
[18:16] <hartmans> Hmm, pana seems to be better than when I last looked but still doesn't have a clear useful purpose
[18:19] <hartmans> I don't know that I have any security concerns with PANA though, just I don't see who will use it concerns
[18:23] %% perry has left.
[18:23] %% perry has arrived.
[18:26] <warlord> hartmans: yes, pana is better than it used to be. AFAICT they are defining 802.1x -- but I need to re-read their docs to verify that situation.
[18:27] %% jaltman has arrived.
[18:27] <jaltman> maybe security considerations could be made a mandatory part of all charters
[18:28] <warlord> hmm.. part of the charter would be interesting.
[18:28] <warlord> Part of the problem I think are some ADs who just don't care about security.
[18:28] <jhutz> does new-work get mail about documents submitted to the iesg?
[18:28] <jaltman> the way I see it, most protocols put off security until the last minute
[18:29] <jaltman> or at least until after the protocol is basically finished
[18:29] <warlord> jhutz: no, i dont think so.l
[18:29] <warlord> jaltman: I think that depends on the protocol.
[18:30] <tlyu> i wonder if people should be reminded that security engineering is still engineering and that there are always tradeoffs involved.
[18:30] <warlord> no, I think people understand that.
[18:31] <perry> "security considerations are deliberately violated by this document"
[18:31] <tlyu> i get the feeling that those of us who work largely in the security arena perhaps try too hard to make things bulletproof, and people in other areas might not make the tradeoff that way.
[18:32] <warlord> "The perfect is the enemy of the good"
[18:33] <hartmans> There are fairly few protocols that do not have some applications where you need strong security. As such I think most protocols should support it even if they have weaker modes like self-signed certs
[18:34] <hartmans> warlord - I see many fewer instances of that than repititions of that statement
[18:34] %% leg has left.
[18:34] %% leg has arrived.
[18:34] <warlord> hartmans: then I dont think you have looked around hard?
[18:35] <hartmans> No, I think we're very good about repeating simple advice;)
[18:36] <warlord> True..
[18:36] <tlyu> it may be that some protocol designers feel that the threat models that we security folk use are unrealistic for their applications...
[18:37] <warlord> Oh, I'm sure they do. "who would ever attack this protocol?"
[18:37] <hartmans> tlyu - and I believe that in most cases they have some users who do need our full threat model
[18:37] <warlord> sure..
[18:37] <tlyu> in that case, perhaps we should find a way to make it clear to them that they will have users who require our threat model.
[18:38] <tlyu> i suspect that part of it is that security experts realize that you need to design for the worst possible case because *someone* will need it.
[18:38] <hartmans> Tom we should in fact do that and also make it clear that we want to help them make the normal case easier
[18:38] <tlyu> sam - and the second part of it is perhaps getting lost
[18:39] <hartmans> But we also need to realize that you should write protocols that can be configured for the common cases even if they support a worst-case mode
[18:39] <hartmans> I'd agree the second part tends to get lost at two places
[18:39] <hartmans> First by some security people and second sometimes by the people who listen to us
[18:40] %% Eliot has arrived.
[18:40] <hartmans> For example I'll often say something along the lines of "The config that is vulnerable to active attack is easy and I agree, can we now spend abig chunk of time on the really secure configuration"
[18:40] <hartmans> And people don't notice that I've agreed the easy to deploy option needs to exist.
[18:41] <warlord> I think you need to be more explicit in step #2
[18:41] %% ole has left.
[18:43] %% jaltman has left.
[18:43] %% Eliot has left.
[18:45] %% danwing has left.
[18:45] %% Eliot has arrived.
[18:45] %% jhutz has left.
[18:45] %% Eliot has left.
[18:46] %% Eliot has arrived.
[18:46] %% hartmans has left.
[18:46] %% tlyu has left.
[18:46] %% leg has left.
[18:47] %% Eliot has left.
[18:47] %% warlord has left.
[18:47] %% jis (the lame duck) has left.
[18:48] %% jis (the lame duck) has arrived.
[18:48] %% jis (the lame duck) has left.
[18:48] %% mrose has left.
[18:50] %% leg has arrived.
[18:53] %% leg has left.
[18:54] %% mrp has left.
[19:01] %% rlbob has left.
[19:05] %% shep has left.
[19:05] %% shep has arrived.
[19:05] %% shep has left.
[19:53] %% perry has left.
[21:55] %% leg has arrived.
[21:55] %% leg has left.