Re: [Cfrg] [TLS] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

[Andrey Jivsov <[e-mail]>]

On 03/02/2017 05:54 PM, Hal Murray wrote:
> 
> [e-mail] said:
>> I also think that counting in blocks is cleaner. Counting in bytes is a
>> close alternative. 
> 
> Does counting bytes work?  If the real limit is blocks, I think you will have 
> to round up the byte count when you send a partial block.
> 
> If re-keying too often isn't too expensive, you could get a safe answer by 
> counting bytes and assuming that every byte went in a separate block.
> 
> You might want to round down many more orders of magnitude so the re-key code 
> gets exercised often enough.  Or maybe provide a back door to set the limit 
> so that path can be tested with reasonable resources.
> 

I like the idea of setting the rekey limits, so that the code can be
tested. There is no 3DES in TLS 1.3.


You refer to some under-counting.

The worst case is mod 16 = 1 byte sized TLS records, in which case the
"tails" will only be counted as 1 block per 16 TLS records v.s. desired
16. We are undercounting less than one 16-byte block per record.

One can count in record_size_in_bytes + 16 as one solution (overcount).

However, is it true that 1-byte terminal blocks must be counted as full
16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs
with distinguishing game. With 1-byte plaintext / ciphertext we are not
making statements about two values from the 1^128 members space. Rather,
we are discussing two values from the tiny 256 members space. Also, a
truncated AES-GCM encryption behaves as PRF and not PRP.