[03:54:23] --- mrex has left: Replaced by new connection
[03:54:57] --- mrex has joined
[03:58:02] --- Jabber-Wile has joined
[04:01:19] --- ldondeti has joined
[04:03:54] --- dumdidum has joined
[04:04:01] <ldondeti> Folks this is Lakshminath
[04:04:04] --- alexis has joined
[04:04:10] <ldondeti> I have the token to relay questions from the jabber room
[04:04:21] <ldondeti> other people are also welcome to do it of course :)
[04:06:08] --- Simon Josefsson has joined
[04:07:10] --- rlbob has joined
[04:08:49] --- mtcarrasco has joined
[04:09:52] --- kasumigaura has joined
[04:10:54] --- miaofuyou has joined
[04:11:00] --- dumdidum has left: Replaced by new connection
[04:11:34] --- dumdidum has joined
[04:12:18] <Simon Josefsson> [is there a jabber scribe?]
[04:13:03] <ldondeti> we didn't have any volunteers
[04:15:35] --- teemuk has joined
[04:17:37] --- cnewman@jabber.org has joined
[04:18:43] <cnewman@jabber.org> I'll jabber scribe
[04:19:04] <cnewman@jabber.org> Ekr at front, current slide is: "Open Issue: Hash Agility for Signatures"
[04:19:20] <Simon Josefsson> [thanks!]
[04:20:47] <cnewman@jabber.org> http://www3.ietf.org/proceedings/07mar/slides/tls-2.pdf
[04:21:50] <cnewman@jabber.org> Anyone object to basic proposal for Hash Agility?
[04:22:56] <cnewman@jabber.org> Paul has issue with waiting on NIST waiting for issues with DSA/ECDSA because NIST changes mind later.
[04:23:14] <cnewman@jabber.org> Paul wants our spec to state requirements even if based on NIST work.
[04:23:41] <mrex> almost never, like ASN.1 and X.509
[04:26:00] <cnewman@jabber.org> Simon, is the audio working alright?
[04:26:19] <mrex> audio is fine for me
[04:26:31] <Simon Josefsson> [Yes, it works well. Pointers to slide is the most important I would want.]
[04:26:56] <Simon Josefsson> [Rather, pointers to what's on the screen in the room. I can find the slides myself..]
[04:33:11] <cnewman@jabber.org> On slide "Open Issue: Alerts"
[04:38:45] --- tls has joined
[04:39:34] <mrex> having servers send alerts to help troubleshooting will be good. But we need to get the most common Browser fixed badly to show info about the SSL alert to the user, right now it provides a completely useless error message upon a fatal SSL alert (doesn't even tell it did an SSL handshake)
[04:40:50] <cnewman@jabber.org> Slide: "Background: NSA Suite B"
[04:41:19] --- jhutz@jis.mit.edu/owl has joined
[04:41:53] <cnewman@jabber.org> Slide "What is this document?" (11)
[04:42:07] <jhutz@jis.mit.edu/owl> Unfortunately, you can't change the most common browser. All you can do is change what that maps to, and that takes time.
[04:43:16] <cnewman@jabber.org> Slide "What to do?" (12)
[04:44:10] <cnewman@jabber.org> Any comments on making this a WG document?
[04:45:33] <cnewman@jabber.org> [room seems positive about making it WG document]
[04:46:33] <Simon Josefsson> What about patent concerns regarding ECC, and to a lesser extent, SHA-2?
[04:48:04] <ldondeti> do we worry about patent issues on each cryptosuite?
[04:48:23] <ldondeti> besides wasn't there an ECC disclosure related to the US Govt. usage?
[04:48:56] --- lebo has joined
[04:49:25] <Simon Josefsson> for standards track documents, I believe we should worry about patent issues
[04:49:29] <ldondeti> ok
[04:49:31] <ldondeti> I will ask
[04:49:35] <ldondeti> :)
[04:49:39] <Simon Josefsson> thanks :)
[04:50:42] <ldondeti> current discussion is on whether we'll standardize other governments's ciphersuites
[04:51:15] <Simon Josefsson> [for the record, the ipr disclosure for rfc4492 can be found for draft-ietf-tls-ecc at https://datatracker.ietf.org/public/ipr_search.cgi?option=document_search&document_search=tls-ecc]
[04:53:39] <mrex> The given link reads "No IPR disclosures related to RFC 4492 have been submitted"
[04:53:56] <ldondeti> Ekr says ECC were advanced as Exp and that applies here as well
[04:54:06] <Simon Josefsson> mrex: see https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=695
[04:54:13] <Simon Josefsson> it says "and other IETF specifications using ECC technology"
[04:54:46] <ldondeti> correction: info, not Exp
[04:55:39] <cnewman@jabber.org> Slide "AES-GCM Ciphersuites for TLS 1.2"
[04:56:09] --- jimsch has joined
[04:56:13] --- jhutz@jis.mit.edu/owl has left: Disconnected
[04:57:03] <cnewman@jabber.org> Slide "Open Issues"
[04:57:27] --- jimsch has left
[05:00:16] <cnewman@jabber.org> New presentation by Yaron: "TEE: TLS Authentication Using EAP"
[05:00:28] <mrex> Certicom IPR statement says "Certicom will, upon request, provide a nonexclusive, royalty free patent license, to manufacturers to permit end users (including both client and server sides), to use the patents in schedule A when implementing any of these protocols, including those requiring third party certificates provided the certificate is obtained from a licensed Certificate Authority (CA)." -- Wow, this is going to be costly -- and it seems you can not use your own CA (OUCH!)
[05:00:31] <cnewman@jabber.org> Slide "Goals"
[05:01:35] <cnewman@jabber.org> http://www3.ietf.org/proceedings/07mar/slides/tls-3.pdf
[05:01:57] <ldondeti> this is an interesting topic
[05:02:18] <ldondeti> we had a brief discussion on this in EMU yesterday
[05:02:30] <ldondeti> I thought there was something about 3748 applicability statement
[05:02:35] <ldondeti> well, let's see what happens ...
[05:02:53] <Simon Josefsson> mrex: yes, that is my problem with the ecc work.
[05:05:26] --- miaofuyou has left
[05:05:47] <cnewman@jabber.org> Slide "Protocol Example"
[05:06:01] <Simon Josefsson> fyi, eap in tls handshake is already specified and deployed via http://tools.ietf.org/html/draft-funk-tls-inner-application-extension-02 -- I've implemented it, but it is a rather ugly extension
[05:06:58] <cnewman@jabber.org> Slide "Protocol Principles"
[05:07:02] <ldondeti> I don't recall whether this was the reference, but Hannes was talking abt someone dropping this work and the current authors are reviving the work now
[05:07:10] <ldondeti> Hannes said this at EMU
[05:08:02] <cnewman@jabber.org> Last slide "Thank You!"
[05:08:11] <cnewman@jabber.org> Back to "Protocol Principles" slide
[05:09:35] <ldondeti> the discussion about EAP applicability statement starts
[05:09:36] <ldondeti> :)
[05:10:58] --- tls has left: Computer went to sleep
[05:15:14] --- tls has joined
[05:18:21] <cnewman@jabber.org> Slide "draft-rescorla-tls-extractor" (13)
[05:18:56] <cnewman@jabber.org> Slide "Motivation" (14)
[05:20:24] <cnewman@jabber.org> Slide "General Mechanism" (15)
[05:21:09] <cnewman@jabber.org> Slide "Comments from Pasi" (16)
[05:24:05] <Simon Josefsson> How about "First Come First Serve" rules for labels prefixed with "EXTRACTOR" or "X-" or whatever? I believe a FCFS rule is useful.
[05:24:47] <ldondeti> so Ekr says the "EXTRACTOR" part may be removed
[05:24:50] <ldondeti> based on Pasi's comments
[05:24:57] <ldondeti> IANA to manage uniqueness
[05:25:17] <ldondeti> and that has moved into "spec required" IANA guidance
[05:25:33] --- miaofuyou has joined
[05:28:23] --- alexis has left
[05:34:01] <mrex> Why does everyone (EAP-TLS, GSSAPI-TLS) want to mess so throroughly with the existing TLS state machine ?
[05:35:26] <cnewman@jabber.org> The SASL folks just want channel bindings to TLS, so I wouldn't say "everyone". :-)
[05:36:41] <Simon Josefsson> Since you mention SASL, I think using this method to generate the channel binding is much better than re-using the TLS finished messages. see http://tools.ietf.org/wg/sasl/draft-josefsson-sasl-tls-cb-00.txt
[05:36:51] <mrex> I hope we can find an approach so that when the next bunch of guys comes around with a proposal we will NOT have to touch the TLS protocol stack AT ALL.
[05:37:31] <Simon Josefsson> Having just ONE TLS extension that includes a list of IANA labels would solve that, I think. Then it would be clear that each of those labels correspond to extracting keys in some way.
[05:38:11] --- clancy has joined
[05:39:05] --- clancy has left: Logged out
[05:42:27] <mrex> In some (most? all?) scenarios, the applications want to retain possibility to frob the native APIs of the extension in various ways, so integrating the extension deeply into the TLS state machine will create serious problems (leaky abstraction).
[05:43:34] <mrex> One of the problems that comes up is "who is keeping the state and how" for the extension and across TLS session resume
[05:44:34] <ldondeti> Done!
[05:44:47] --- cnewman@jabber.org has left
[05:45:11] <mrex> except for the unnecessary SPNEOG overhead, I think that rfc4559 is fine
[05:45:23] --- mtcarrasco has left
[05:45:52] --- rlbob has left
[05:46:23] --- ldondeti has left
[05:46:33] <mrex> being able to authenticate the client securely at the application level in the (load-balanced) backend scales quite well
[05:48:16] --- miaofuyou has left
[05:49:22] --- tls has left: Computer went to sleep
[05:50:26] --- lebo has left
[05:52:43] --- mrex has left
[05:52:43] --- Jabber-Wile has left
[05:56:29] --- Simon Josefsson has left
[05:56:56] --- teemuk has left
[06:04:19] --- kasumigaura has left
[07:01:54] --- dumdidum has left
[08:19:06] --- jaltman has joined
[14:03:58] --- jaltman has left