IETF
saag
saag@jabber.ietf.org
Thursday, 8 November 2012< ^ >
ogud has set the subject to: IETF-84 SAAG is over
Room Configuration

GMT+0
[17:58:28] jpc joins the room
[17:59:21] jpc leaves the room
[19:43:37] yuioku.yj joins the room
[19:59:21] nico joins the room
[20:00:29] nico leaves the room: Replaced by new connection
[20:00:32] SM joins the room
[20:01:44] yaron.sheffer joins the room
[20:04:34] sftcd joins the room
[20:05:57] =JeffH joins the room
[20:08:32] tony.l.hansen joins the room
[20:09:57] derek joins the room
[20:12:38] hillbrad joins the room
[20:13:03] yngve_n_pettersen joins the room
[20:13:24] Barry Leiba joins the room
[20:13:35] hillbrad has set the subject to: http://tools.ietf.org/agenda/85/agenda-85-saag.html
[20:15:13] kazubu joins the room
[20:15:40] m&m joins the room
[20:15:53] cw joins the room
[20:15:54] lef.jpn joins the room
[20:16:22] Ken Murchison joins the room
[20:17:58] dseomn joins the room
[20:19:49] Dave Mitton joins the room
[20:23:23] kivinen joins the room
[20:23:31] Ken Murchison leaves the room
[20:24:40] Andrew Sullivan joins the room
[20:25:29] nico joins the room
[20:25:33] jpc joins the room
[20:26:27] cw leaves the room
[20:28:34] hartmans joins the room
[20:30:50] bkihara.l joins the room
[20:33:17] jpc leaves the room
[20:36:53] Ken Murchison joins the room
[20:37:26] <sftcd> boom box arrives for those at the back of the saag room
[20:37:37] <Andrew Sullivan> hurray!
[20:37:48] <sftcd> let's see what happens when he connects
[20:37:53] <Andrew Sullivan> now if only we could get people not to write whole paragraphs on the slides. . .
[20:37:58] <Andrew Sullivan> (good thing they're online.)
[20:38:29] EKR joins the room
[20:39:08] <sftcd> lemme know if the audio at the back improves
[20:39:18] <Andrew Sullivan> will do
[20:39:24] <EKR > is someone scribing? Where are we at?
[20:39:35] <sftcd> tatu nearing end of his slides
[20:39:46] <sftcd> not scribing slides
[20:39:47] <EKR > thx
[20:39:48] <hartmans> gee, and does my ssh implementation actually give me any useful tools for managing the keys?
[20:39:52] <hartmans> Or how about host key rollover?
[20:40:22] <hartmans> Do you think that perhaps there are operational reasons having to do with ssh implementation design choices that might lead an organization to use 14000 servers with the same key?
[20:40:27] <Andrew Sullivan> yes, audio better now
[20:40:31] <sftcd> great t
[20:40:46] <derek> I was asked to relay any questions from here.. which I will do if there are any.
[20:40:56] jpc joins the room
[20:42:14] <nico> i do blame the protocol, actually
[20:42:37] <nico> well, not entirely, because there are more alternatives now
[20:43:12] <nico> pki and kerberos at least make the key mgmt and access revocation aspects of this much easier
[20:43:22] <hartmans> nico: O, yeah, the protocol causes some of the implementation difficulties at least on the host key side.
[20:43:24] <nico> and auditing, too, a bit anyways
[20:43:35] <hartmans> I'm not sure I can think of protocol issues that create the authorized_keys problem.
[20:44:12] <nico> authorization, however, beyond initial login authz, is a much harder problem, one that neither pki nor kerberos solve today
[20:44:40] <nico> authorized_keys results from lack of a protocol for authz
[20:44:54] <nico> is that enough to blame the protocol?
[20:45:13] <derek> There's not a good way to roll a host key.
[20:45:27] <nico> but at least certificates and tickets can deliver lots more data than just a public key
[20:45:32] <hartmans> derek: We know and agree.
[20:45:58] <nico> derek: if you use pki or kerberos for host auth the. host key rollover is easy
[20:46:33] <derek> does anyone use x509 w/ ssh?
[20:46:40] <derek> is there even an implementation of that?
[20:46:42] <nico> but even when you use kerberos you often end up needing host pubkeys because OpenSSH refuses to take gss-keyex patches!
[20:46:56] <derek> also, how does one use kerberos for "host auth"?
[20:46:56] <nico> derek: iirc Solaris ships one, yes
[20:47:07] <nico> though that is after my time in Solaris eng
[20:47:22] <nico> derek: with gss-keyex
[20:47:31] <derek> .. which isn't in OpenSSH.
[20:47:36] <nico> i k
[20:47:47] <nico> sucks
[20:47:59] <derek> why do they refuse the patches?
[20:48:05] <nico> complexity
[20:48:14] <nico> long story
[20:48:21] <nico> others know it better
[20:48:32] <sftcd> tatu's last slide
[20:48:40] <nico> or, at least, the details are currently swapped out in my brain
[20:49:36] <nico> i know several orgs that patch OpenSSH to support gss-keyex
[20:49:51] <nico> and so they replace the ssh from the distro they normally use
[20:50:10] <nico> precisely so as to be able to not have to manage ssh public host keys!
[20:50:19] cw joins the room
[20:51:25] <sftcd> nico: problems are similar with krb/pki but those solve some parts of this but not authorized_keys problem
[20:51:45] <sftcd> (sf scribing while scribe in queue, someone else feel free to help)
[20:52:44] <sftcd> nico: promting use of krb/pki could help as could adding a protocol for authorized_keys <something>
[20:53:06] <sftcd> nicp
[20:53:13] <sftcd> nico: there is stuff to do
[20:53:48] <sftcd> justin richer: looking at it wrong way 'round, why are sysadmins doing it? 'cause passwords/2FA suck in usability, <analogy>
[20:54:02] EKR leaves the room
[20:54:06] <hartmans> sftcd: key rollover is actually much simpler with pki and kerberos
[20:54:21] <nico> i should have mentioned a few more things
[20:54:23] <sftcd> jr: instead of ways to educate, try develop stuff that doesn't suck
[20:54:28] <hartmans> o, you're scribing never mind.
[20:54:33] <sftcd> phb: +1 to jr
[20:54:41] <sftcd> phb: i invented something
[20:54:43] <sftcd> oops
[20:55:05] <nico> orgs that patch, that kerberos helps a bit with auditing
[20:55:07] ogud joins the room
[20:55:19] <sftcd> phb: pki features are badly designed but do exist, don't necessarily need hsms, but tpms help
[20:55:47] <sftcd> phb: cyberwar is ongoing now, bet's that ssh is part of that
[20:56:06] <sftcd> dan harkins: why SHOULD for remove keys no longer needed?
[20:56:11] <sftcd> tatu: maybe s/SHOULD/MUST/g
[20:56:44] <sftcd> tim shepherd: didn't learn much about ssh, but you opened my eyes that now may be worse than .rhosts
[20:56:58] <sftcd> scribe back scribing
[20:59:50] EKR joins the room
[21:03:17] ogud leaves the room
[21:04:12] EKR leaves the room
[21:04:51] EKR joins the room
[21:04:58] <sftcd> btw, we're interested to know how useful this kind of presentation is (when we asked for suggestions this was suggested) that's fine at open-mic or here
[21:05:46] <Barry Leiba> I like this sort of presentation in general. We often hear about exploits and don't have the details.
[21:06:14] EKR leaves the room
[21:06:43] Satoru Kanno joins the room
[21:07:02] EKR joins the room
[21:07:50] <EKR > fwiw: http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html
[21:07:59] <nico> iirc silverlight also had interfaces that could be exploited to implement BEAST
[21:08:10] <EKR > nico: this has been claimed but I have never seen a demonstration
[21:08:20] Ken Murchison leaves the room
[21:08:28] <nico> i haven't either, but i have seen source code
[21:08:42] <nico> in a pastie
[21:08:53] <nico> that is gone now
[21:09:00] <EKR > Hmm...
[21:09:21] <nico> someone posted it as a comment on a blog entry of mine where i explained the use of flush operations
[21:09:47] <nico> the comment was something like "you said flush!!!!!1!!"
[21:09:55] <nico> and a pastie url
[21:10:15] <EKR > Well, I'd certainly be interested in seeing a description of what the alleged problem is
[21:10:24] <yngve_n_pettersen> Mic: In case people are interested, just a little bit of statictics about TLS server deployment, this week: TLS 1.1 support 2.97% (0.59% as the highest version), TLS 1.2 support 3.97% (and yes, that means 1.58% of servers support TLS 1.2 but not TLS 1.1)
[21:10:48] <nico> i dont recall if or where i might have saved that code
[21:10:51] <nico> i can look
[21:11:37] <nico> yngve: meaning the rest only do 1.0?
[21:11:43] EKR leaves the room
[21:12:06] Stefans joins the room
[21:12:17] <yngve_n_pettersen> 0.897% only support SSL v3
[21:12:49] <sftcd> yngve - I guess Derek will go the mic at the end of the slides
[21:12:54] <yngve_n_pettersen> 94.4% support max TLS 1.0
[21:12:55] <nico> none does tls 1.3 or up, i gather :^)
[21:13:23] <derek> Yeah, I was going to wait until the end.
[21:14:29] Karen O'Donoghue joins the room
[21:16:21] im joins the room
[21:16:29] <SM> :-)
[21:16:48] Shoichi Sakane joins the room
[21:16:51] EKR joins the room
[21:17:03] Ken Murchison joins the room
[21:17:37] <kazubu> http://tools.ietf.org/html/draft-kihara-compression-considered-harmful
[21:18:00] cabo joins the room
[21:18:00] <sftcd> the author is looking for input on his I-D
[21:18:05] <sftcd> sftcd scribing again
[21:18:32] <sftcd> nico: the lower in the stack you compress, the more <something>
[21:18:58] <sftcd> phb: this isn't a TLS issue, its a cookies issue, caused by session cookies as bearer tokens
[21:19:23] <sftcd> phb: better to provide alternatives in HTTP looks like digest but as easy to key as cookies then it could be better
[21:19:32] <nico> the lower in the stack that compression occurs, the harder it is to make sure that compression isn't enabling a CRIME attack
[21:19:35] <hartmans> re: phb: aren't there potential other attacks with the exposure?
[21:19:43] <sftcd> joe salowey: important to check CRIME vs. other protocols
[21:19:49] <nico> also, compression often causes plaintext leaks
[21:19:49] <hartmans> I mean yes cookies are the bad part.
[21:19:52] <bkihara.l> no. this is not only for cookies. if a web page returns query string, atackers can guess sensitive data in the body.
[21:19:52] <derek> re phb: why not just rekey the cookie on every request?
[21:20:06] <nico> e.g., voice compression
[21:21:33] PHB joins the room
[21:21:39] <bkihara.l> I had an experiment to sniff credit card numbers in the ideal mock page. I succeeded to guess card numbers even TLS compression and SPDY are disabled, because HTTP body compression is enabled.
[21:21:47] semery joins the room
[21:21:47] <nico> whereas deciding to compress at the app layer allows the app to compress only data where it's harmless, like bulk data transfers
[21:22:05] cw leaves the room: Disconnected: session closed
[21:22:22] <nico> bkihara: cool! it's not just cookies
[21:22:24] hillbrad leaves the room
[21:22:40] <bkihara.l> agree. compression should be applied in the app layer and apps are responsible not to mix things.
[21:22:53] <EKR > the problem here is that the web inherently intermixes data
[21:23:23] <nico> right, a web page can't compress at all then
[21:23:46] <hartmans> Is there any work on security models in this space...talking about what security property you don't have when you mix data like this for example?
[21:24:07] <EKR > yeah, consider the case where, for instance, the attacker gets to supply data like a blog comment
[21:24:18] <EKR > Or, the title of an email
[21:24:22] <hartmans> I'm trying to wrap my head around the class of problem not just the specific attacks and am not being as successful as I'd like
[21:24:31] <PHB> In general, cookies are the only data most people send in a Web browser that needs confidentiality.
[21:24:41] <PHB> They don't send their password a bazillion times
[21:24:54] <nico> phb: and credit card numbers and so on
[21:24:59] <EKR > or, you know, my email
[21:25:08] <PHB> Other applications using TLS don't have javascript involved
[21:25:20] <EKR > What do you mean they don't have JS involved?
[21:25:25] <PHB> nico: again, getting them to resend them multiple times...
[21:25:29] <nico> phb: we're talking about compression
[21:25:45] <nico> phb: compression leaks by itself
[21:25:47] <EKR > I don't think it's necessarily true that we are going to have attacks that require a lot of repeated transmission
[21:25:49] <PHB> Javascript is what puts a turing machine in the hands of the attacker
[21:25:54] cw joins the room
[21:26:06] <EKR > Sure, but that's the standard thing on the Web.
[21:26:07] <hartmans> phb: App writers would probably like security primitives where they don't have to care these issues. I suspect that we cannot build such primitives (at least when compression is involved) but would like to have a model that allows me to convince myself of that.
[21:26:22] EKR leaves the room
[21:26:26] <PHB> nico: yes, compression leaks, but does it leak more than content length?
[21:26:51] <nico> first, compression leaks, no JS necessary. second, there's webmail and so on -- most apps are available as web apps
[21:26:52] <PHB> If I know the length of the movie you are viewing in bytes, I probably know what your preferences are ....
[21:27:05] <nico> phb: yes
[21:27:16] <nico> voice, ...
[21:27:24] Stefans leaves the room
[21:27:39] <nico> the point is that the user-agent can't know if compression is unsafe
[21:27:48] <nico> therefore the user-agent must not compress
[21:27:51] <sftcd> I'm guessing Carsten's thing has a list: https://www.ietf.org/mailman/listinfo/solace
[21:27:57] Stefans joins the room
[21:28:53] <yngve_n_pettersen> Hmmmm: In case anyone are interested: https://www.ietf.org does not send a resumable TLS Session, did accept TLS Session Ticket; https://tools.ietf.org does send resumable sessions, but are only resumable for the IP address that sent it, the same for Session Tickets
[21:29:18] <nico> hartmans: i'm convinced that lower layers cannot safely decide when compression is safe
[21:29:36] <bkihara.l> deeply agree with nico
[21:29:39] <nico> well, except that bulk data transfers can probably be detected heuristically
[21:29:46] <nico> but even then
[21:29:54] <PHB> I have IPR in this area: rights reserved
[21:29:58] <PHB> sorry
[21:30:10] <nico> i'd rather, say, that SFTP have transfer encodings than rely on ssh to compress
[21:30:23] <hartmans> phb: ok, please file the disclosure.
[21:30:33] <hartmans> This clearly counts as a contribution and you clearly participated:-)
[21:30:35] <PHB> yeah, was going to anyway.
[21:31:19] <nico> phb: this area being the last presentation?
[21:31:24] <nico> or compression?
[21:31:32] EKR joins the room
[21:31:33] <sftcd> scribe hat on
[21:32:23] <bkihara.l> FYI, Androids still have webviews and default browsers with TLS compression enabled.
[21:32:40] <nico> u
[21:32:53] <PHB> Have to specify an authentic RAND policy,
[21:33:02] <PHB> this area being the last presentation
[21:33:20] <nico> thx for the clarification
[21:33:37] EKR leaves the room
[21:34:25] hillbrad joins the room
[21:35:25] <PHB> I think RAND should mean that all the license terms are public and people can pick and choose any terms
[21:35:52] ogud joins the room
[21:36:52] EKR joins the room
[21:43:17] hartmans leaves the room
[21:43:58] EKR leaves the room
[21:45:04] <PHB> Hey, why not just run Jscript in all the routers. That would make everything better - right?
[21:45:14] EKR joins the room
[21:46:42] EKR leaves the room
[21:48:10] Ken Murchison leaves the room
[21:48:16] hartmans joins the room
[21:48:21] hillbrad leaves the room
[21:48:34] Sean Turner joins the room
[21:48:47] Barry Leiba leaves the room
[21:49:50] jpc leaves the room
[21:50:07] <PHB> Is the draft going to tell people how to do bitmining
[21:54:01] Ken Murchison joins the room
[21:56:06] Ken Murchison leaves the room
[21:56:06] Ken Murchison joins the room
[21:56:24] <nico> google thinks the datatracker page for the pcp wg is in French and offers to translate it
[21:56:50] Karen O'Donoghue leaves the room
[21:57:21] cw leaves the room
[21:57:21] m&m leaves the room: Disconnected: connection closed
[21:57:22] lef.jpn leaves the room
[21:57:26] hartmans leaves the room
[21:57:37] <derek> See y'all in Orlando!
[21:57:42] derek leaves the room
[21:57:47] SM leaves the room
[21:57:49] PHB leaves the room
[21:57:53] Dave Mitton leaves the room
[21:57:53] dseomn leaves the room
[21:57:53] kazubu leaves the room
[21:57:53] yngve_n_pettersen leaves the room
[21:58:22] =JeffH leaves the room: Logged out
[21:58:29] Andrew Sullivan leaves the room
[21:58:31] Stefans leaves the room
[21:58:50] Shoichi Sakane leaves the room
[21:59:07] yuioku.yj leaves the room
[21:59:51] Satoru Kanno leaves the room
[21:59:51] sftcd leaves the room
[21:59:56] kivinen leaves the room
[22:00:11] bkihara.l leaves the room
[22:00:28] yaron.sheffer leaves the room
[22:01:21] Sean Turner leaves the room
[22:02:35] Ken Murchison leaves the room
[22:02:36] Ken Murchison joins the room
[22:05:32] Karen O'Donoghue joins the room
[22:05:49] Karen O'Donoghue leaves the room
[22:08:36] Ken Murchison leaves the room
[22:08:51] ogud leaves the room
[22:11:36] semery leaves the room
[22:15:02] Stefans joins the room
[22:15:38] Stefans leaves the room
[22:19:21] sftcd joins the room
[22:20:25] sftcd leaves the room
[22:23:28] EKR joins the room
[22:24:04] m&m joins the room
[22:25:02] Ken Murchison joins the room
[22:25:36] Ken Murchison leaves the room
[22:28:55] cabo leaves the room
[22:32:09] Sean Turner joins the room
[22:34:09] dseomn joins the room
[22:34:23] dseomn leaves the room
[22:34:46] PHB joins the room
[22:35:12] PHB leaves the room
[22:36:25] Sean Turner leaves the room
[22:36:31] Sean Turner joins the room
[22:40:02] Shoichi Sakane joins the room
[22:41:39] EKR leaves the room
[22:43:46] cabo joins the room
[22:44:54] EKR joins the room
[22:45:37] ogud joins the room
[22:46:29] EKR leaves the room
[22:47:45] Satoru Kanno joins the room
[22:48:27] Satoru Kanno leaves the room
[22:48:41] Sean Turner leaves the room
[22:51:34] nico leaves the room
[22:53:43] Shoichi Sakane leaves the room
[22:58:33] kazubu joins the room
[23:10:11] lef.jpn joins the room
[23:41:04] cabo leaves the room
[23:43:56] kazubu leaves the room
[23:44:05] kazubu joins the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!