Friday, October 24, 2014< ^ >
nico has set the subject to: KITTEN WG | | NOTE WELL:
Room Configuration
Room Occupants

[12:57:38] nico leaves the room
[15:08:12] kaduk joins the room
[15:19:22] nico joins the room
[16:58:45] <nico> hi kaduk
[17:00:12] <kaduk> Hey Nico
[17:00:25] <nico> just submitted PKCROSS -03
[17:00:28] <nico> fwiw
[17:01:20] <kaduk> cool.
[17:01:34] <nico> I need to dig up AGL's DANE stapling docs
[17:01:38] <nico> and code
[17:01:52] <nico> IIRC there was some C++ code for stapled DANE validation
[17:02:00] <kaduk> I heard TLS had moved away from DANE stapling, but didn't hear why
[17:02:21] <nico> there were a variety of reasons:
[17:02:31] <nico> - slow deployment of DNSSEC and DANE
[17:02:51] <nico> - use of RSA 1024-bit keys at the root
[17:03:06] <nico> that doesn't mean it's not appropriate for PKCROSS
[17:03:35] <nico> there may have been other reasons too; IIRC I exchanged e-mail with AGL on this topic
[17:03:40] <nico> i could dig it up
[17:03:53] <nico> anyways, DANE is much easier to use than PKIX for new apps
[17:04:39] <nico> on the client/issuer side it's just a script run from cron that uses dig(1) or similar to lookup the relevant RRs and which then encodes them for stapling
[17:05:02] <kaduk> Having to deal with PKIX trust anchors is kind of unpleasant, sure.
[17:05:03] <nico> on the RP side it's a surprisingly small bit of code to validate the stapled RRs
[17:05:35] <nico> there's no need even to do DNS lookups with any kind of resolver, except in the script mentioned above
[17:06:06] <nico> various signature validation steps are highly cacheable
[17:06:24] <nico> so this is very appealing
[17:06:30] <kaduk> "You say 'cacheable', I wonder 'timing attack?'"
[17:06:36] <kaduk> (probably not, here)
[17:06:45] <nico> not here
[17:07:03] <nico> a peer gives you a chain like
[17:07:22] <nico> well,, bar.example., example.
[17:09:19] <nico> and say you find that you've already validated bar.example., so you can stop there; the cache would be indexed by the signing public key, and the expiration on the cache would be the TTL of the relevant RR at cache entry insertion time
[17:09:59] <nico> timing will reveal what was in the cache
[17:10:35] <nico> it's data-/key-dependent timing of crypto operations that would be bad
[17:11:04] <kaduk> I mean, it leaks that you visited something under bar.example already.  But, so does, like DNS itself (mostly).
[17:17:25] <nico> no, that someone did
[17:17:42] <nico> the RP here is a KDC
[17:18:11] <nico> the client is attempting to get a TGT using PKINIT/PKCROSS
[17:18:51] <nico> the client gets to see that some other client with an issuer below bar.example. (but not visited the same KDC
[17:19:59] <nico> if this were a problem the KDC could still stop validating at bar.example. and hold off sending the reply until as much time passes as it took to validate bar.example. (and example.)
[17:20:14] <nico> and dedicate CPU cycles to other requests in the meantime
[17:20:17] <kaduk> Sure
[19:24:14] <nico>
[19:25:05] <nico> kaduk: the two reasons AGL gave me for dropping stapled DANE were: the RSA 1024-bit key sizes, and the lack of CT
[19:26:09] <kaduk> *nods*
[19:29:27] <nico> re: RSA, RSA 2K sigs are large, but RSA is twice as fast at verification as Ed25519, but then again, Ed25519 signature verification can be batched, so if you have long domainnames (not likely) or high load that can be batched...
[19:30:57] <nico> it might be useful to write an IPC service for Ed25519 signature verification batching, where N IPC clients submit one or two signatures to verify, and the daemon batches up to 64 signatures or however many arrive in the time it takes to verify 64 signatures, whichever comes sooner
[20:12:59] kaduk leaves the room