IETF
kitten
kitten@jabber.ietf.org
Friday, October 3, 2014< ^ >
stpeter has set the subject to: KITTEN WG | http://tools.ietf.org/wg/kitten/
Room Configuration
Room Occupants

GMT+0
[15:56:14] nico joins the room
[16:05:50] kaduk joins the room
[16:13:23] <nico> hi Ben
[16:13:38] <nico> the /topic here should always have a NOTE WELL
[16:13:47] <nico> you might want to mention that to someone
[16:13:50] <kaduk> Hi Nico
[16:14:48] <kaduk> Hmm.  That would require knowing whom...
[16:15:49] <nico> :)
[16:16:14] nico has set the subject to: KITTEN WG | http://tools.ietf.org/wg/kitten/ | NOTE WELL
[16:16:23] <nico> no, no need to know whom...
[16:16:46] nico has set the subject to: KITTEN WG | http://tools.ietf.org/wg/kitten/ | NOTE WELL: https://www.ietf.org/about/note-well.html
[16:16:51] <nico> there!
[16:18:30] <kaduk> Thanks.
[16:20:50] <nico> we should invite npmccallum
[16:20:54] <nico> and hartmans
[16:20:55] <nico> and...
[16:23:08] <kaduk> "and mention it on the list"
[16:24:04] <nico> sigh; of course
[16:24:10] <nico> that's the ellipsis
[16:24:12] <nico> anyways
[16:24:19] <nico> should I?
[16:24:23] <nico> or would you rather?
[16:24:28] <nico> you're co-chair
[16:24:39] <kaduk> Well, I can't commit to reliably being here yet :-/
[16:25:38] <nico> well, no one can
[16:25:44] <nico> however we have the logger
[16:25:51] <nico> and you'd not have to be here reliably
[16:25:53] <kaduk> That's true...
[16:26:12] <nico> a chair isn't needed to do everything a WG does...
[16:26:21] <kaduk> Also true.
[16:26:31] <kaduk> Ideally, the chair doesn't have to do much at all, comparatively speaking.
[16:47:11] <nico> I should add that I'd be happy to not extend RFC3961 at all and instead either extend the AP-REP or share the enctype number namespace with RFC3961 so as to not have to change RFC4121 enctype negotiation
[16:47:29] <nico> in fact, this is is probably the fastest route to implementation
[16:47:39] <nico> and it's not incompatible with later extending RFC3961
[17:00:13] <nico> the fastest, cheapest way to implement would probably be to not extend RFC3961, but I could see strong objections to that (e.g., from Jeff A.)
[17:00:17] <nico> bbl
[17:45:04] kaduk leaves the room
[19:16:48] kaduk joins the room
[19:31:30] <nico> kaduk: I think the extension to RFC3961 would be rather simple
[19:32:23] <nico> there'd be no need to say anything about Kerberos, oddly enough, because there would be no encryption and decryption functions for the new enctypes
[19:32:41] <nico> instead there'd be authenticated_encryption and authenticated_decryption functions
[19:33:16] <kaduk> Hmm.
[19:33:27] <nico> Kerberos would fail to use them
[19:33:48] <nico> KDCs would have to fail to select them, but that's as far as Kerberos goes
[19:34:15] <nico> you could use them for AP sub-keys, but not with KRB-SAFE/PRIV/CRED
[19:34:49] <nico> there would also not be any checksum functions for the new enctypes
[19:35:30] <nico> if you want a MIC you must use authenticated_encryption without a payload to be encrypted input, just an additional data input
[20:39:48] <nico> with a lot of care [regarding IVs] it might even be possible to have a single enctype that uses AES CTS HMAC-whatever for the original RFC3961 crypto and AES OCB for the AEAD functions
[20:40:04] <nico> that would be super sweet
[20:43:27] <nico> FYI, this is informative
[20:43:28] <nico> http://web.cs.ucdavis.edu/~rogaway/ocb/performance/
[20:44:49] <nico> it'd be nice if we had a way to measure performance of RFC3961 enctypes with OpenSSL
[20:44:56] <nico> to get it closer to apples to apples
[20:45:31] <kaduk> ISTR that performance measurements with OpenSSL can be challenging.
[20:46:20] <nico> of... anything?  or RFC3961?
[20:46:49] <kaduk> of anything, yeah.
Something about openssl perf using a different backend selector than the library would, maybe.
[20:47:22] <nico> as long as for openssl speed it's the same for all ciphers...
[20:47:54] <nico> if OpenSSL elsewhere does things that could be improved, no problem
[20:48:05] <nico> if it's openssl speed that does bad things, that's another story
[20:49:52] <nico> Heimdal has a simple test_crypto.c program I might hack on to measure raw RFC3961 encryption w/ keyed checksums and AES w/ OCB, though it wouldn't be the fairest test because the GSS path is important
[20:50:05] <nico> but it'd be hard to measure the GSS path... without building it
[20:50:29] <kaduk> Well, yes.
[20:50:56] <nico> anyways, I've convinced myself that if we don't extend RFC3961 then I just need to extend the initial security context token and the AP-REP to support negotiation of the new thing
[20:51:08] <nico> and if we do extend 3961 then I don't
[20:51:29] <nico> protocol-wise that that's the hardest part
[20:51:50] <nico> code-wise if we don't extend 3961 there's a lot of room for unfair comparisons
[20:52:18] <nico> we might not extend RFC3961 but still implement this using the same crypto framework just to keep things fair
[20:54:02] <nico> which brings me to having to ask MIT and Heimdal maintainers whether they'd want a new framework code-wise if we don't extend RFC3961
[20:54:24] <nico> each might give different answers
[20:55:08] <nico> ditto additional implementations (e.g., Windows), but that's why I'd prefer to do something that is nominally an RFC3961 extension, and let each implementor decide whether they'll do it that way or not
[20:56:22] <nico> as to enctypes worth adding...
[20:58:37] <nico> AES-GCM (because Intel, for example, publishes code for that optimized for some of their CPUs, and GCM seems popular enough to soon get full-blown HW support)
AES-OCB (because it's much faster in software than GCCM [GCM in software, not AES])
Chacha-Poly1305 (because a new stream cipher would be nice to have, but also if it happens to be faster than AES-GCM or AES-OCB)
[21:30:03] kaduk leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!