I also think that counting in blocks is cleaner. Counting in bytes is a close alternative.
I have a few nits below: On 03/02/2017 01:44 PM, Brian Smith wrote: > Aaron Zauner <a...@azet.org> wrote: >> I'm not sure that text on key-usage limits in blocks in a spec >> that fundamentally deals in records is less confusing, quite >> the opposite (at least to me). > > 1. Consider an implementation that negotiates with another > implementation to use a very large record size such as 1MB records. If > the limit is specified in terms of records then the limit would need > to be readjusted to the new max record size, or else the new extension > is potentially unsafe to use. This shows that specifying the limits in > terms of records is brittle. Hm, while I agree that counting in wrong units is the main problem here, we over-count with records, which means that we re-key faster than needed. > 2. If it is only safe to use an AES-GCM key for a certain number of > blocks, where in the code is the best place to enforce the limit on > the number of blocks? IMO, it is better to enforce it in the AES-GCM > implementation itself, underneath the TLS layer. In that case the > limit is best expressed in terms of the number of blocks. Specifying > the limit in terms of records would be optimizing for implementations > that enforce the limit at the wrong layer of abstraction. Given that the event of reaching the limit requires TLS-level action, checking the limit at the TLS level seems reasonable. The lower-level block-cipher code should still have the logic to error out (using a more relaxed limit). > >> As I pointed out earlier: I strongly recommend that any changes >> to the spec are as clear als possible to engineers >> (non-crypto/math people) -- e.g. why the spec is suddenly >> dealing in blocks instead of records et cetera. Again; I really >> don't see any reason to change text here - to me all suggested >> changes are even more confusing. > > Given a limit in blocks, the arithmetic to keep track of the number of > blocks is trivial, and very similar to the arithmetic that's already > needed to split up a large byte stream into records and keep track of > the record sequence number. Also please consider counting in bytes. This may be more natural, especially with AES-GCM that doesn't expose higher levels to the block size granularity (as much as CBC does, anyway). > > Cheers, > Brian > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
