Re: [TLS] draft-ietf-tls-record-limit-01

[Hubert Kario <[e-mail]>]

On Monday, 25 September 2017 04:12:09 CEST Martin Thomson wrote:
> Hi Hannes,
> 
> I appreciate that the way that you calculate the available space is
> difficult, but I did think very long and hard about this.
> 
> The current approach makes it easier for someone to *comply* with the
> size limit and I'd like to retain that property as much as possible.
> I want people to implement and deploy this extension in every stack
> even if they don't have a way to set a limit lower than 16k.
> 
> The only alternative metric I can think of is the size of the
> ciphertext.  The other overheads are either fixed or hard to measure
> at the (D)TLS layer.  Other measures are too situation-dependent, such
> as whether you need to count TCP headers, and leads to other problems
> like what you do about TCP header extensions.
> 
> A change to the length of ciphertext makes it more difficult to
> implement at the point when you fragment messages generically.  And
> that means more testing.  As it is, I replaced a constant
> (MAX_FRAGMENT_LENGTH) with a variable (recordSizeLimit) and the code
> was basically done.  

my understanding of this draft was that the TLS1.3 ContentType is included in 
the record limit while it is not included in the TLS 1.3 maximum payload size

> Requiring calculations here adds risk and you
> want as many people who are NOT building an implementation for
> constrained devices to implement this as possible.
> 
> Yes, if you want byte-accurate numbers, the configuration calculation
> is going to need:
> 
> * information about the lower layers of the stack (TCP/UDP/IP) and how
> much space they need
> * information about TLS versions for the explicit IV
> * information about enabled cipher suites and their maximum expansion
> 
> The good news is that if you use TLS 1.3, all the AEADs have an
> expansion of 16 octets (unless you are using the truncated CMAC suite,
> which I have never seen myself) and records add 5 octets.  The whole
> CBC EtM/MtE business is a mess for sure, but I think that we're
> putting the costs in the right place.
> 
> As Hubert observes, you can always assume the worst case expansion,
> which is safe and relatively easy.
> 
> Note that TLS 1.3 padding is covered, so no concern there.
> 
> On Thu, Sep 14, 2017 at 12:17 AM, Hannes Tschofenig
> 
> <[e-mail]> wrote:
> > Hi Hubert,
> > 
> > your proposal to include the worst case calculations are indeed another
> > possibility. It provides more information for the developer than the
> > current version of the document.
> > 
> > A few additional remarks:
> > 
> > On 09/12/2017 08:11 PM, Hubert Kario wrote:
> >> On Tuesday, 12 September 2017 14:30:48 CEST Hannes Tschofenig wrote:
> >>> Hi Martin,
> >>> 
> >>> I have implemented the record size extension into mbed TLS. It can be
> >>> found at https://github.com/ARMmbed/mbedtls/pull/1088
> >>> 
> >>> There is only one problem that remains to be addressed IMHO. This
> >>> extension was developed to address the problem of devices with small
> >>> RAM. Application developers have to configure their embedded TLS stack
> >>> in such a way that the parameters configured with this TLS extensions
> >>> match the available hardware.
> >>> 
> >>> The record_size_limit helps a lot already but does not quite to the
> >>> final goal since it uses an artificial metric for deciding when to
> >>> fragment records.
> >>> 
> >>> Currently, a developer has to understand various security concepts to
> >>> get this right, namely
> >>> 
> >>>  * Ciphersuite negotiated (and the overhead associated with it, such as
> >>> 
> >>> tag length),
> >>> 
> >>>  * DTLS vs. TLS record layer header differences,
> >>>  * potential compression being applied.
> >>> 
> >>> Additionally, there is, of course, other header information that needs
> >>> to be considered in the overall buffer size calculation, such as TCP or
> >>> UDP, IP and potentially any lower layer headers.
> >>> 
> >>> I just think that this is too much to ask for from an ordinary
> >>> developer.
> >>> 
> >>> Hence, I would suggest to use a different metric so that the developer
> >>> can be certain that at least from a DTLS/TLS layer there are not records
> >>> being sent that exceed the indicated threshold.
> >>> 
> >>> If you think that this idea is worthwhile to entertain then I will make
> >>> a proposal.
> >> 
> >> yes, I too found the necessary calculation rather complex and thus hard
> >> to get right
> >> 
> >> that being said, if you are ok with "good enough" solutions (for memory
> >> allocation, for verifying correctness of packets it should be exact), the
> >> actual receive buffer for encrypted TLS records has to be only 85 bytes
> >> longer>> 
> >> than the value you send to server:
> >>  - max MAC size - 48 bytes
> >>  - max IV size - 16 bytes
> >>  - header size - 5 bytes
> > 
> > ... unless DTLS 1.2 is used where it is 13 bytes. For DTLS 1.3 is most
> > likely different since we are trying to optimize the record layer format.
> > 
> >>  - max block size for CBC ciphers - 16 bytes
> >>  - max padding - 16 bytes
> > 
> > ... unless TLS/DTLS 1.3 is used where padding is a different meaning.
> > 
> >> since MAC size is the exact multiple of block size, the padding starts in
> >> worst possible place if the MAC size is arranged on block boundary. Thus
> >> the worst case scenario padding length is 16 bytes. Same in case of EtM.> 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > TLS mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic