On Fri, Jan 01, 2016 at 08:04:11AM +0100, Aaron Zauner wrote: > * Aaron Zauner <a...@azet.org> [01/01/2016 07:35:26] wrote: > > This might be a good time to point again to my existing AES-OCB > > draft that hasn't really seen a lot of discussion nor love lately. > > It expired but I've recently updated the draft (not yet uploaded > > to IETF as I'm waiting for implementer feedback from two particular > > sources). The update has something to do with how GCM is implemented > > in some stacks though, see: > > https://github.com/azet/draft-zauner-tls-aes-ocb/commit/26c2fff7808fc88bf47e5d097f2ff5ca23201029 > > Having said that, it's probably also a good idea for me to mention > that the OCB designers point out that: > ``` > [...] > > Birthday-bound attacks (as well as good cryptographic hygine) > motivate rekeying well in advance of birthday-bound concerns. In RFC > 7253 we say that a given a key should be used to encrypt at most 248 > blocks (about 280 terabytes). > ``` -- http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#ferguson > > Aaron
On topic of existing recomendations, SECSH recommends rekeying after 2^32 blocks (64GB) with 128-bit block ciphers like AES[1]. This is obviously a lot more conservative than the above quoted recommendation. Also, it occurs to me that if key update makes sense to even include depends on the decided threshold. If it is 64GB, then it makes sense to include. If it is 256TB, then probably not (pseudo- wrapping TLS sequence numbers is probably not a good usecase, as data volumes would need to be enormous for that to become an issue). [1] It also has recommendation to rekey before 2^32 packets, but that comes from SSH sequence numbers being 32-bit. TLS sequence numbers are 64-bit. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
