[15:31:26] --- hartmans@jis.mit.edu/owl has joined
[16:02:14] --- jimsch1 has joined
[16:03:47] --- mrex has joined
[16:04:28] <hartmans@jis.mit.edu/owl> Paul and Don are scribing non-jabber. We currently don't have a jabber scribe
[16:05:17] --- kivinen has joined
[16:05:19] --- touch has joined
[16:05:32] --- kivinen has left
[16:05:35] --- raeburn has joined
[16:05:36] --- touch has left
[16:05:56] --- tlyu@jis.mit.edu has joined
[16:05:57] --- Joe Touch has joined
[16:06:36] --- ryu has joined
[16:07:22] --- sftcd has joined
[16:08:18] --- Jabber-Wile has joined
[16:08:58] --- EronenP has joined
[16:26:37] --- pni has joined
[16:27:09] --- pni has left
[16:28:22] --- john.zhao has joined
[16:28:50] --- john.zhao has left
[16:31:48] --- semery@jis.mit.edu has joined
[16:42:51] --- Jabber-Wile has left: Replaced by new connection
[16:43:16] --- Jabber-Wile has joined
[16:49:09] --- ryu has left: Disconnected
[16:59:35] --- raeburn has left
[16:59:52] --- ekr has joined
[17:00:08] <ekr> So, where is this being discussed
[17:00:23] --- jhutz has joined
[17:00:55] <jhutz> where is what being discussed? sandy's work?
[17:01:12] <jhutz> I suspect "nowhere, yet", but that'd be a reasonable question.
[17:04:29] <ekr> I'm not trying to be difficult--you'll see that later--but this is really quite unclear
[17:04:36] <ekr> And I'm trying to understand the context
[17:07:21] <ekr> there's only one key for each connection, not separate in each direction? that seems unclean
[17:07:30] <Joe Touch> Sandy is presenting the result of the design team in TCPM.
[17:07:45] <Joe Touch> And there are different keys in each direction.
[17:07:50] <ekr> OK.
[17:08:16] <ekr> well, ok, but that's not clear from this talk. Is there an I-D I can read?
[17:10:59] <ekr> this all seems unnecessarily detailed in its description of the internal state of the system
[17:11:08] <jhutz> > I'm not trying to be difficult--you'll see that later Somehow, I doubt that. :-)
[17:11:13] <Joe Touch> draft-ietf-tcpm-tcp-auth-opt is the ID
[17:11:16] <ekr> thank you.
[17:11:43] <jhutz> I think ipsec is similarly unnecessarily detailed
[17:12:16] <ekr> jhutz: not disagreeing with you there.
[17:16:59] <sftcd> why does an even length value in the option mean no key id?
[17:17:24] <Joe Touch> please review the doc. some of the need for requirements is to be specific as to the impact on TCP, FWIW.
[17:17:40] <ekr> That's an odd design choice
[17:21:14] <ekr> I propose they only be allowed two slides each but they have to alternate
[17:21:45] <tlyu@jis.mit.edu> someone should point the desk mic down
[17:23:53] <ekr> I'm pretty unconvinced by this argument.
[17:24:01] <ekr> This is why you have automatic key management
[17:24:50] <ekr> HMAC-SHA1 and HMAC-SHA-256
[17:28:28] <Joe Touch> what's an "odd design choice"?
[17:29:17] <sftcd> length/2==0 => no keyid
[17:30:50] <Joe Touch> Oh - that may be an artifact. The info as to whether there is a KeyID can be encoded in the key tuple, and need not be determined by the odd/even info.
[17:31:11] <Joe Touch> The reason we thought of using odd to indicate no keyid is because most MACs are even.
[17:31:46] <sftcd> ta. not a big deal, but looks a bit odd
[17:33:11] --- nico has joined
[17:33:23] <Joe Touch> yeah. it works, but it may not be necessary; that's in the list of possible things to cleanup.
[17:35:42] <jhutz> tom, someone could turn the gain down on that mic. IIRC the mixer channels are well labelled
[17:37:46] <Joe Touch> PS - there is a list of "TO DO" items in the draft... sec 1.3
[17:38:27] <jhutz> stefan is talking about identity selection
[17:39:20] <tlyu@jis.mit.edu> "who do you want to be today?"
[17:40:57] <nico> name?
[17:41:10] <nico> oh, it's still Stefan
[17:41:36] <nico> suddenly he sounded like someone at the mic
[17:41:41] --- john.zhao has joined
[17:42:39] <ekr> uh,,,
[17:43:37] <tlyu@jis.mit.edu> did he say string match on the DER-encoded credential?
[17:44:36] <ekr> Yes.
[17:44:43] --- semery@jis.mit.edu has left
[17:44:54] <ekr> And yes, it's crazed
[17:44:56] --- semery@jis.mit.edu has joined
[17:45:03] <nico> that's... weird
[17:45:22] <nico> I think Stefan is following this approach to keep things generic
[17:45:22] <tlyu@jis.mit.edu> well it might be ok if your false positive rate is sufficiently low
[17:45:42] <ekr> sure, but it's going to have all these bizarre surprise failure modes
[17:45:49] <nico> but I think it'd be a lot wiser to defined per-security mechanism identity/credential selection critieria
[17:46:35] <ekr> You know what they say, if you have a problem and you think "i'll use a regular expression". Now you have two problems
[17:46:41] <nico> "bizarre surprise failure modes" would be bad if it resulted security vulnerabilities
[17:48:01] <EronenP> ekr: true. but he's proposing ASN.1, and now you have lot more than two problems :-)
[17:48:23] <tlyu@jis.mit.edu> would you rather he used XML?
[17:48:24] <nico> and searching encoded ASN.1 data
[17:49:07] --- bdr has joined
[17:49:28] <EronenP> no sure xml would be any better
[17:49:34] <nico> my comment is: I don't believe that defining per-mechanism criteria that avoid this problem is so hard that search the encoded data would be better
[17:49:45] <nico> ekr: hell yes it's useful
[17:49:54] --- kivinen has joined
[17:51:07] <nico> ekr: people *do* have many identities
[17:51:12] <nico> forget PKIX for now
[17:51:37] <hartmans@jis.mit.edu/owl> Yes, we have this problem in the kerberos space
[17:51:51] <jhutz> yes, this is a real problem
[17:51:52] <semery@jis.mit.edu> Sounds like GSS-API naming extension attributes and mech inquiry could be relevant here.
[17:52:04] <ekr> Well, I know nothing about how things are done in GSS.
[17:52:09] <ekr> with respect to this.
[17:52:10] <nico> I think generic criteria could be: a) federation name, b) mechanism name, c) optional user name
[17:52:13] <ekr> But it's not a problem in TLS.
[17:52:17] <ekr> AFAIK
[17:52:17] <jhutz> it's a problem for tls, too
[17:52:22] <nico> per-mechanism criteria could be much more detailed
[17:52:24] <tlyu@jis.mit.edu> i've personally run into the X.509 client cert selection problem, but it was because Safari insisted on attempting to use the expired cert to authenticate.
[17:52:46] <semery@jis.mit.edu> We still need to flesh out the attributes.
[17:52:52] <ekr> In my experience, TLS clients simply ignore the offered CA list.
[17:52:56] <nico> semery: yes, if you've got an implementation using the GSS-API
[17:53:04] --- Joe Touch has left
[17:53:05] <hartmans@jis.mit.edu/owl> We could always re-encode in xer and then use xpath
[17:53:26] <ekr> I suggest that we allow the relying party to send a perl script which matches your cert
[17:53:27] <nico> ekr: take the TLS as deployed blinders off
[17:53:38] <nico> sam: !
[17:53:45] <jhutz> That's not been my esperience; in fact, that's the only thing that doesn't make selecting among certs painful for me
[17:54:14] <ekr> Nico, I think I have a pretty accurate vision of how TLS could be, not simply as deployed, so spare me the lecture.
[17:54:17] <nico> ekr: or even the TLS blinder
[17:54:30] <hartmans@jis.mit.edu/owl> Nico, it sounds like you are claiming that ekr's tls deployment experience is inaccurate. I think that's unlikely to be true. I think it is a reasonable statement that tls may some day have this problem and may have this problem in specific deployments today
[17:54:43] <nico> sam: no
[17:54:49] <ekr> Well, things may have changed. It used to be the case that people didn't check this stuff.
[17:55:00] <ekr> It also still is the case that practically nobody has client certs
[17:55:08] <nico> I am arguing that whether TLS client users have many certs, or even any certs is not the main issue here
[17:55:27] <nico> we have an identity selection problem, even if in practice we don't have it at the client end of TLS connections
[17:55:29] <hartmans@jis.mit.edu/owl> I think it is a critical issues to the value of this mechanism to TLS
[17:55:30] <ekr> It certainly is if we're discussing a mechanism which could be grafted into TLS.
[17:55:37] --- Jabber-Wile has left
[17:55:40] <ekr> I could care less what you do with GSS
[17:55:44] <jhutz> I've had multiple client certs at once, each for use with small private sites using a private CA, and my browser picks the right one. I assume that's because it's using the offered CA list, because I don't know what other criteria could be used.
[17:55:58] <ekr> Well, then maybe the clients have gotten better
[17:56:12] <nico> ekr: I suspect that Stefan wants this grafted into TLS, yes
[17:56:21] <nico> if that's true, then you're correct
[17:56:23] <ekr> Again, this is a very rare situation in practice.
[17:56:26] <jhutz> Unfortunately, that's really a stopgap - if we ever had a large-scale infrastructure for authenticating users, then people would be more likely to have multiple certs for different identites signed by the same CA (or traceable to the same root)
[17:56:30] <nico> we need to consider how useful it is in that context
[17:56:57] <ekr> Well, as usual, I like to wait to see problems first before I design solutions for them
[17:57:01] <nico> but I'm asserting that identity selection hints are generally useful not just in the context of protocols that support PKIX
[17:57:07] <nico> certs
[17:57:13] <jhutz> > practically nobody has client certs Do you think that is likely ever to change?
[17:57:13] --- jimsch1 has left
[17:57:35] <ekr> I'm not sure how likely it is to change. I thought it was going to change 10 years ago, so I guess I was wrong then.
[17:57:37] <hartmans@jis.mit.edu/owl> Nico, need is really strong and you would be more credible if you justified assertions like that. need != I think it would be good if especially in the presence of well stated objections like "no one would use this"
[17:57:42] <ekr> I could just as well be wrong now.
[17:57:57] --- sftcd has left
[17:57:59] <ekr> But again, it seems to me we should see the problem first
[17:58:04] <jhutz> It seems to be uncommon in practice _if you only consider TLS_. Some of us see it all the time.
[17:58:11] <hartmans@jis.mit.edu/owl> But now I go meet with ekr
[17:58:20] <nico> heh
[17:58:23] <semery@jis.mit.edu> We could have scenarios where we have certs, krb-creds, passwd...
[17:58:33] <nico> semery: exactly
[17:58:42] <nico> this typically comes up in SSH use cases
[17:58:49] <nico> how many pubkeys do you have?
[17:58:57] <semery@jis.mit.edu> One.
[17:59:07] <kivinen> several.
[17:59:19] <nico> how many krb5 princs in how many krb5 "federations" (islands of x-realm trusts disconnected from each other)
[17:59:24] <nico> ?
[17:59:33] <nico> how many altogether?
[17:59:44] <nico> how many web username+passwords do you have?
[17:59:49] --- kivinen has left
[17:59:50] <nico> (a jillion)
[18:00:00] --- tlyu@jis.mit.edu has left
[18:00:01] <semery@jis.mit.edu> and counting...
[18:00:41] <nico> and we're all trying to deploy web SSO / federated identity solutions
[18:00:41] --- EronenP has left
[18:01:04] <nico> which should convert those to credentials more akin to PKIX or Kerberos V
[18:01:47] --- semery@jis.mit.edu has left: Disconnected
[18:02:34] <nico> someone might want to turn the mics off
[18:02:52] <nico> we're hearing Tim talking to someone
[18:02:54] <nico> :)
[18:03:04] --- nico has left
[18:04:09] --- bdr has left
[18:16:10] --- jhutz has left: Disconnected
[18:24:55] --- john.zhao has left
[18:45:12] --- florent.parent@gmail.com has joined
[19:12:04] --- florent.parent@gmail.com has left
[23:02:55] --- ekr has left