[01:51:05] --- mrichardson has joined
[11:41:49] --- mrichardson has left
[11:41:49] --- mrichardson has joined
[13:41:06] --- ryu.inada has joined
[13:41:17] --- ryu.inada has left
[14:21:18] --- saadatmalik has joined
[15:40:19] --- mrex has joined
[15:50:55] --- ryu.inada has joined
[15:52:47] --- ldondeti has joined
[15:54:10] --- behcet.sarikaya has joined
[15:55:23] --- behcet.sarikaya has left
[15:55:50] <mrex> are people are already "wearing" mics, or are there just the security geeks in the front within mic range?
[15:56:51] <mrex> the noise on audiocast channel 7 is pretty awful
[15:57:26] <mrex> sounds like a helicopter
[15:57:39] --- raeburn has joined
[15:58:25] --- behcet.sarikaya has joined
[15:59:24] --- tlyu@jis.mit.edu has joined
[15:59:26] --- jaltman has joined
[15:59:29] <raeburn> Martin: How does Russ sound now?
[15:59:36] <raeburn> (He's using a mic.)
[15:59:50] --- hartmans has joined
[16:00:12] <mrex> he sounds fine -- lound and clear. There's just a pretty annoying distortion on the line that sounds like a helicopter
[16:00:18] <jaltman> there will be no jabber scribing for the working group reports which were sent to the saag@mit.edu mailing list
[16:01:13] <mrex> (the distortion has been present on channel 7 since monday)
[16:01:26] --- the_galv has joined
[16:02:06] --- ekr has joined
[16:02:21] <ekr> The agenda here is wg reports first?
[16:02:22] --- jhutz has joined
[16:02:31] <hartmans> Yes. And they don't know how to fix the distortion
[16:02:51] --- patchvonbraun has joined
[16:03:05] <jhutz> has someone filed a ticket about the distortion? have the people noticing the distortion been able to characterize it?
[16:03:17] <jhutz> wg reports first, then bof reports, then invited presentations.
[16:03:26] <ekr> Cool.
[16:03:37] <jhutz> the reports will not be scribed; everyone has sent or will send summaries to saag
[16:03:37] <ekr> Can you arrange to just log when they're occurring?
[16:03:37] --- raeburn has left: Disconnected
[16:04:02] <mrichardson> EMU.
[16:04:06] --- danwing has joined
[16:04:38] --- raeburn has joined
[16:04:57] <jhutz> yes, we can log which WG is reporting
[16:05:12] <jhutz> russ tells me he has slides from all the presenters, and they have all been uploaded to the IETF meeting site.
[16:05:14] <jhutz> MSEC
[16:05:33] --- nov has joined
[16:07:41] --- jaltman has left
[16:07:56] <jhutz> BTNS
[16:08:44] --- jaltman has joined
[16:09:38] <jaltman> DKIM
[16:09:51] --- dcrocker has joined
[16:10:45] --- kivinen has joined
[16:11:24] <jaltman> KRB-WG
[16:12:00] <jhutz> KITTEN
[16:15:02] <jaltman> NEA
[16:16:05] <jaltman> HOKEY
[16:16:29] --- jon-ietf has joined
[16:17:25] <jhutz> SASL
[16:17:37] --- ekr has left: Logged out
[16:17:57] --- ekr has joined
[16:18:55] <jaltman> PKIX
[16:20:54] --- behcet.sarikaya has left
[16:22:12] <jhutz> S/MIME
[16:22:48] --- dumdidum has joined
[16:23:32] <jaltman> ISMS
[16:25:45] --- jis has joined
[16:26:03] <jhutz> LTANS
[16:28:29] <jaltman> BOFs: SPKM
[16:29:13] --- geoff has joined
[16:29:19] --- Jabber-Wile has joined
[16:30:23] <jaltman> KEYPROV
[16:30:57] <jhutz> Well, it wasn't just her and phill; there were a lot of people in the room
[16:31:08] <ekr> It actuallylook reasonably sound.
[16:31:18] <ekr> at least when I read it.
[16:32:42] <jhutz> keyprov? yeah; we tweaked the charter text a bit, but it was pretty good even before. I only skimmed the proposed protocols, though
[16:33:24] --- kdz has joined
[16:33:40] <ldondeti> I am concerned about how GBA, EAP and Keyprov stuff can live side by side
[16:33:53] <ldondeti> I have some answers, but want to understand the applicability fully
[16:34:03] <ldondeti> if anyone has insight, I want to hear
[16:34:17] <ekr> well keyprov==provisioning securid cards.
[16:34:34] <jhutz> well, it's not just that
[16:34:38] <hartmans> What is GBA?
[16:34:45] <jhutz> "Game Boy Advance" ?
[16:34:47] <ekr> Isn't that the date rape drug?
[16:34:51] --- stefans has joined
[16:34:51] <ldondeti> Generic Bootstrapping Architecture
[16:35:38] --- saag has joined
[16:35:45] <hartmans> Is GBA an IETF thing?
[16:35:54] <ldondeti> 3GPP (and 3GPP2 eventually) specify it to establish Mobile Terminal to Server key provisioning based on credentials shared between the Mobile and the AAA
[16:36:02] <ldondeti> the server can be any application server
[16:36:15] <ldondeti> broadcast service for instance is an application
[16:36:28] <jaltman> Audio stream: http://videolab.uoregon.edu/events/ietf/ietf677.m3u
[16:36:31] <ldondeti> anyway, that's a short blurb abt it; can talk more about it offline
[16:36:51] <hartmans> I'm sorry, but we cannot stop 3GPP and 3GPP2 from doing stupid things. And we cannot account for all the things that other people do in our work.
[16:36:56] <ldondeti> :)
[16:37:10] <ldondeti> I don't disagree
[16:37:32] --- pigdog has joined
[16:37:32] <ldondeti> I try my best on things being designed now, where I have a say
[16:37:35] <jaltman> Presentation Slides: http://www3.ietf.org/proceedings/06nov/slides/saag-1.ppt
[16:37:44] <ldondeti> things designed in the past of course are out of our control
[16:37:44] <hartmans> So, GBA is not IETF and we don't care about it. EAP is for network access. keyprov is for tokens.
[16:37:56] <jaltman> slide 5
[16:37:58] <ldondeti> jeff says keyprov is more
[16:38:11] <jaltman> slide 6
[16:38:18] <ldondeti> is it?
[16:38:38] <hartmans> Open question. I hope to convince the wg to limit scope exactly so we don't have a conflict.
[16:38:52] <ldondeti> cool
[16:39:15] <jaltman> slide 7
[16:39:40] --- vidya has joined
[16:40:25] <jaltman> slide 8
[16:41:07] <ldondeti> does anyone else thinks this is good?
[16:41:25] <jaltman> Slide 9
[16:41:38] <jaltman> slide 10
[16:42:24] <tlyu@jis.mit.edu> you cannot enumerate all possible attacks in finite time
[16:42:36] <jhutz> keyprov is/appears to be about provisioning symmetric keys, including cases where the device doesn't know the key in advance (i.e. it's not just securid enrollment). There seems to be disagreement about what sorts of symmetric key provisioning should be in scope
[16:42:42] <jaltman> slide 11 (final)
[16:43:12] <mrex> XML is beyond repair
[16:43:39] --- cmadson55-ietf has joined
[16:43:44] <jaltman> Henning: we have formal specifications (ABNF) that seems to have done nothing to protect against buffer overflows in implementations because of an inability to specify fixed lengths
[16:44:10] --- Suz has joined
[16:44:17] <jaltman> Henning: these are all good steps, reviews have gotten better, but improvement is not appearing
[16:44:52] <jaltman> Venkat: Security Considerations notes are good, but implementation notes are missing
[16:45:03] <mrex> PKIX and XML/WSS keeps inflating specs until there is no implementation left that doesn't have at least one thousand serious bugs
[16:45:54] <jaltman> EKR: your advice boils down to formal language parsers must be perfect when they are not.
[16:46:29] <jaltman> EKR: implementing parsers is hard. translating from specs to code is hard. people make mistakes.
[16:48:12] <jaltman> Warren: I did not assume you mentioned inventing a formal language for use in RFCs. Venkat: confirmed W: so I don't know what you are proposing
[16:48:17] <mrex> many programmers are extremely lazy and neither test function return values (especially malloc() return values for small quantities) and neither to use plausibility tests on data which they don't really care about. The RSA v1.5 padding problem with RSA keys using public exponent 3 is a lazy programmer example
[16:48:32] <mrex> (pkcs#1)
[16:48:40] <jaltman> W: many incompetent programmers in the world. Even when the specs are good, programmers don't read them
[16:48:47] <mrichardson> I would suggest that making the specifications *HARDER* to read would make things more secure.
[16:49:14] <mrichardson> when the pointy-haired-manager sits down to consider implementing, they might read a bit of the spec, and decide... "this is hard, I'd better put my best guy on it" vs
[16:49:28] <mrichardson> "this looks easy, let's have a co-op do it"
[16:50:36] <mrex> it is extremely difficult to say which amount of packets is an attack, and the number is going to change significantly over time
[16:50:39] <jhutz> PHB's don't read specs
[16:50:52] <jaltman> Stephen Kent: how much longer will it take for documents to get approved while we argue over how to specify things so that programmers never make mistakes
[16:51:00] <jhutz> certainly, they don't read past the first page, which today is all boilerplate
[16:51:15] --- shep has joined
[16:51:21] <mrex> and at high volumes it would be quite expensive to distinguish the good from the bad packets
[16:52:16] <mrichardson> on a completely unrelated note: anyone understand what the setkey format is that permits ipcomp to be used for ESP-tunnel mode?
[16:53:37] <mrex> the migration of apps vendors from dedicated communication channels with app-specific protocols to http and web-browsers as frontends is making it extremely difficult for servers to shape traffic if the load maxes out the server -- i.e. keep servicing existing clients and reject new requests
[16:53:44] --- cabo has joined
[16:54:08] <mrex> because it is so difficult to distinguish "existing" and "new" at the lower levels of the protocol stacks
[16:56:39] <mrex> app programmers usually do not want to throw an error if they think they might continue by ignoring user/network supplied data -- this is an area where we need to educate app programmers and encourage them to abort with an error if the data is NOT within the spec
[16:56:48] --- dcrocker has left
[16:57:07] <mrichardson> mrex: not enough. they need to say, "I expected foo, but I got bar"
[16:57:27] <mrichardson> because otherwise, the bug report/support transition is impossible.
[16:57:44] <jaltman> Steve Bellovin presents
[16:58:03] <jaltman> http://www3.ietf.org/proceedings/06nov/slides/saag-3.pdf
[16:58:04] <mrex> well, the error messages that MSIE throws when somethings go wrong is clearly the worst conceivable approach
[16:58:15] <jhutz> Is that like "Alfred Hitchcock Presents" ?
[16:58:20] <jaltman> slide 2
[16:58:28] <jaltman> slide 3
[16:58:40] <pigdog> "just because you're paranoid doesn't mean they're NOT out to get you" ;-)
[16:58:47] <jaltman> slide 4
[16:58:52] <cabo> To the people dissing formal specification languages: Neither NFSv4 nor ROHCv2 would exist without them. You can learn something from these (partially long-term) experiments...
[16:59:13] --- ldondeti has left: Logging off
[16:59:57] <jaltman> slide 5
[17:00:33] <jaltman> slide 6
[17:01:35] <jaltman> slide 7
[17:01:57] <pigdog> cabo: which rfc is that?
[17:02:33] <jaltman> slide 8
[17:02:59] <jaltman> slide 9
[17:04:09] <jaltman> slide 10
[17:04:59] --- ldondeti has joined
[17:05:20] <jis> The irony that it was a firewall machine
[17:06:46] <jaltman> slide 11
[17:07:19] --- ekr has left
[17:07:24] <cabo> pigdog: NFSv4 is RFC3530, the notation is RFC1832; see also draft-ietf-nfsv4-minorversion1-08.txt. ROHCv2 is still at draft (see draft-ietf-rohc-rfc3095bis-rohcv2-profiles-00.txt, draft-ietf-rohc-tcp-13.txt), notation is draft-ietf-rohc-formal-notation-11.txt. These are all *large* specs, practically impossible to do with a FN (ROHCv1 was done without an FN and had lots of interop issues).
[17:07:40] <pigdog> thx
[17:07:45] --- ekr has joined
[17:08:01] <jaltman> Sam Hartman: Come to the plenary. Steve has noticed there is water. Tonight we will discuss the iceberg
[17:08:33] <ekr> I
[17:08:34] <jaltman> jhutz: one of the features of switches is limiting the number of MAC addresses permitted on a single port
[17:08:49] <ekr> I'm not dissing formal languages really. I just don't think they make much of a security difference.
[17:09:50] <pigdog> in looking at 3530 it is a modest step up from ABNF, but I think the fundamental issue has more to do with semantics rather than syntax.
[17:10:26] <jaltman> Michael: there are often breadcrumbs even if we don't notice them at the time
[17:12:34] <jaltman> Paul Hoffman: the public is hearing more about bot-nets but a small number of UNIX servers are more programmable and can be used to initiate the attacks.
[17:13:03] <cabo> ekr: You are probably right. ASN.1 BER was a overly difficult encoding though, so the ASN.1 experience does not say much about what happens when you move a normal (IETF-style) protocol to a FN. A Good FN can actually make use of some of the knowledge we have about /bad/ protocol encodings and encourage using good ones. These secondary effects will make more of a difference than the primary ones.
[17:13:42] <jaltman> Presentation: http://www3.ietf.org/proceedings/06nov/slides/saag-0.pdf
[17:13:55] <jaltman> slide 1
[17:14:01] <mrichardson> yes, I agree. I wrote one such "formal" packet description language back in 1988. I thought it was useful as documentation, and was machine readable.
[17:14:24] --- tlyu@jis.mit.edu has left: Disconnected
[17:14:44] <jaltman> slide 3
[17:15:50] <jaltman> slide 6
[17:16:01] <jaltman> slide 7
[17:16:27] <jaltman> slide 8
[17:17:03] <jaltman> slide 9
[17:17:22] --- tlyu@jis.mit.edu has joined
[17:17:40] <ekr> This still SteveB?
[17:17:45] <ekr> (I'm over in SIP)
[17:17:57] <vidya> no, Russ
[17:17:59] <mrichardson> no.
[17:18:40] <mrex> yup, the (disabled) USB-port can still be used as an antenna to receive RF from then inside of the computer chassis
[17:19:42] <jaltman> Open Mic.
[17:19:45] <ekr> Yeah, I looked at these slides... kinda clever
[17:19:51] <jaltman> what do the ADs need to know
[17:20:54] --- pigdog has left
[17:21:20] <ekr> Uh, where the cookies are?
[17:21:58] <jhutz> You don't want the AD's to know that; they might eat them!
[17:22:12] <ekr> I think I can beat Sam to the cookies.
[17:22:22] <ekr> What with my mad running skillz.
[17:22:40] --- jon-ietf has left
[17:22:41] <ekr> Now there's a good idea: put the cookies 1/2 mile away....
[17:23:02] <jhutz> sam carries a weapon
[17:23:49] <ekr> That's a good point.
[17:23:59] <kdz> I thought Sam was a weapon.
[17:24:22] <ekr> I see he's got his hair loose today so he can strangle me with it.
[17:26:03] <jis> That was a while ago...
[17:26:53] <jaltman> Paul Hoffman: very impressed with "the summer of code" and the number of undergrads doing serious technical work
[17:26:54] <mrex> set out some incentive -- invite them to an IETF meeting or something like this
[17:27:09] <jis> Ours work for cookies
[17:27:15] <jis> Do we have cookies at the IETF?
[17:27:15] <jaltman> or beer
[17:27:18] <jis> beer!
[17:27:20] <jaltman> or ice cream
[17:27:23] <jaltman> good bye
[17:27:25] <jis> (not that it helps me in Boston)
[17:27:25] --- shep has left
[17:27:29] --- vidya has left
[17:27:29] --- ldondeti has left
[17:27:31] --- jaltman has left
[17:27:32] --- patchvonbraun has left
[17:27:32] --- Suz has left
[17:27:33] --- kdz has left
[17:27:40] --- nov has left: Computer went to sleep
[17:28:07] --- hartmans has left
[17:28:55] --- danwing has left
[17:29:21] --- the_galv has left
[17:31:06] --- raeburn has left: Disconnected
[17:36:36] --- cmadson55-ietf has left: Replaced by new connection
[17:36:36] --- cmadson55-ietf has joined
[17:38:21] --- ryu.inada has left: Disconnected.
[17:40:31] --- kivinen has left
[17:48:23] --- mrichardson has left
[17:48:31] --- jhutz has left
[17:54:59] --- stefans has left
[17:56:51] --- jis has left
[17:57:38] --- Jabber-Wile has left
[18:04:21] --- dumdidum has left
[18:06:32] --- mrex has left
[18:07:17] --- cabo has left: Logged out
[18:12:26] --- saadatmalik has left
[18:14:29] --- cmadson55-ietf has left
[18:15:27] --- tlyu@jis.mit.edu has left: Logged out
[18:17:25] --- saag has left: Logged out
[18:23:19] --- geoff has left
[18:44:53] --- ekr has left
[18:51:37] --- mrichardson has joined
[18:52:26] --- mrichardson has left
[18:52:29] --- mrichardson has joined
[18:52:45] --- mrichardson has left
[20:01:35] --- kdz has joined
[20:45:30] --- kdz has left
[23:36:22] --- mrichardson has joined
[23:56:22] --- mrichardson has left