Re: [TLS] Maximum Fragment Length negotiation

[Hubert Kario]

On Thursday, 1 December 2016 09:43:54 CET Martin Thomson wrote:
> Asking ALL TLS implementations to change to accommodate these things
> is a pretty blunt instrument.  I want to be sure that this is
> necessary.  (FWIW, I think that this is a reasonable request, I would
> probably be OK with a smaller maximum by default even.)

for receiving those messages you don't have to do anything above what the 
specification already requires

for sending the implementations already have to be able to fragment their 
messages - the change is only to make the value that guards those sizes a 
variable instead of being hardcoded

that leaves the matter of negotiation of the value itself - which, while it is 
yet another extension that needs to be supported, it is not exactly complex or 
that requires convoluted logic


> On 1 December 2016 at 00:22, Hubert Kario  wrote:
> > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
> >> On 30 November 2016 at 05:54, Thomas Pornin  wrote:
> >> > Any comments?
> >> 
> >> I'm ambivalent on this generally: though I think that the general
> >> notion is OK, I'm not sure about the details.
> >> 
> >> In particular, you need to be clearer in your motivations: the point
> >> is to ensure that little things (really little things) can talk to any
> >> other TLS implementation.  That seems inherently good, but it might
> >> pay to dig into that some more: why is that good?
> > 
> > because if they can't use TLS, they will create a bespoke protocol, and
> > those have a tendency of being completely broken, on conceptual level,
> > let alone implementation
> > 
> > combine it with the fact that "trusted network" doesn't exist any more and
> > you end up with solutions that are insecure with nobody using them knows
> > they are insecure, especially in IoT space
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic


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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Martin Thomson]

Asking ALL TLS implementations to change to accommodate these things
is a pretty blunt instrument.  I want to be sure that this is
necessary.  (FWIW, I think that this is a reasonable request, I would
probably be OK with a smaller maximum by default even.)

On 1 December 2016 at 00:22, Hubert Kario  wrote:
> On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote:
>> On 30 November 2016 at 05:54, Thomas Pornin  wrote:
>> > Any comments?
>>
>> I'm ambivalent on this generally: though I think that the general
>> notion is OK, I'm not sure about the details.
>>
>> In particular, you need to be clearer in your motivations: the point
>> is to ensure that little things (really little things) can talk to any
>> other TLS implementation.  That seems inherently good, but it might
>> pay to dig into that some more: why is that good?
>
> because if they can't use TLS, they will create a bespoke protocol, and those
> have a tendency of being completely broken, on conceptual level, let alone
> implementation
>
> combine it with the fact that "trusted network" doesn't exist any more and you
> end up with solutions that are insecure with nobody using them knows they are
> insecure, especially in IoT space
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Raja ashok]

Hi Thomas



Your idea of defining a new similar extension is the only choice for us. 
Because as per existing max_fragment_length extension in RFC 6066, client 
should fail if it receives different value from server.

And also your idea of making the new extension as mandatory for TLS1.3 is good, 
as it will be more useful for constraint server.



Earlier in our team also we were discussing about defining new extension 
specially for constraint client and server. I suggest we should include the 
below points for new fragment length extension

  1) As per RFC 6066, if 512 is negotiated then both entity should keep 
buffer of size 805 bytes (5 byte - record header, 512 bytes - data, 256 bytes - 
padding, 32 bytes - MAC). I think we should change this in our new fragment 
extension. If 512 is negotiated then both entity should not send any [D]TLS 
record of size more than that (includes record header and payload).  Because 
the control overhead of 256 bytes padding and 32 bytes MAC are not applicable 
for recent AEAD algorithms. That too in AES_CCM there is no need of padding.

  2) Currently least value supported by max_fragment_length is 512. I 
prefer we should add support for 256 and 128 also. If AES_CCM_8 is used, the 
control overhead on application record is 21 bytes (5 byte - record header, 8 
byte - IV and 8 byte - MIC). If its DTLS record, overhead is 29 bytes. So if 
max fragment length is 128, we get 99 bytes for data. This is more than 
sufficient for a constraint protocol like CoAP.

  Note : Existing max_fragment_length extension cannot be extended to 
support new values like 128 and 256.

  3) If a client sends both old and new extension, then priority should be 
given to new extension. Server MUST not send both the extension.



I feel the current IoT world needs this kind of new extension. This is the time 
to do.



Regards,

Ashok




Raja Ashok VK
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, 
which
is intended only for the person or entity whose address is listed above. Any 
use of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender by
phone or email immediately and delete it!





-Original Message-
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Thomas Pornin
Sent: 30 November 2016 00:25
To: Fossati, Thomas (Nokia - GB)
Cc: tls@ietf.org
Subject: Re: [TLS] Maximum Fragment Length negotiation



On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB)

wrote:

> I like your proposal, but I'm not convinced that overloading the

> semantics of an already existing extension when used in combination

> with a specific version of the protocol is necessarily the best

> strategy.  Besides, I'd like to be able to deploy a similar mechanism

> in 1.2.



Defining a new extension is certainly possible. However, it would then require 
deciding on the intended behaviour when both that new extension and the RFC 
6066 extension are present.



Tentatively, one could try this:



  - The new extension documents the maximum record length supported

by whoever sends it. Encoding is as in RFC 6066: one byte of

value x for a maximum record plaintext length of 2^(x+8) bytes).

We extend that to the whole 1..8 range so that larger records

may be used by implementations who can afford them and obtain

some performance increase by doing so (actual maximum plaintext

length will be slightly less than 65535 bytes becose the length

header is 16-bit and there must be some room for the MAC).



  - If a client sends both the RFC 6066 extension and the new extension,

and the server supports the new extension, then the RFC 6066

extension is ignored and only the new extension is used. A server

MUST NOT send both extensions.



  - All implementations that support the extension MUST have the

ability to apply a shorter size limit than their maximum limit

(this is for _sending_ records).



  - The length sent by the server is the one that will be applied to

subsequent records on the connection, in both directions. This

applies to the whole connection, including subsequent handshakes

(renegotiations), unless both client and server send the new

extension again in a renegotiation (in which case the new length

appplies).



  - If using TLS 1.3, then the 

Re: [TLS] Maximum Fragment Length negotiation

[Martin Thomson]

On 30 November 2016 at 05:54, Thomas Pornin  wrote:
> Any comments?

I'm ambivalent on this generally: though I think that the general
notion is OK, I'm not sure about the details.

In particular, you need to be clearer in your motivations: the point
is to ensure that little things (really little things) can talk to any
other TLS implementation.  That seems inherently good, but it might
pay to dig into that some more: why is that good?

I would be opposed to having an implicit extension in the way you
describe.  If you are going to require this, then you need to require
the client to send the extension.  I would also be opposed to a new
extension when the existing one is adequate - or it could be made to
be adequate.

I agree that the current extension semantics are not good.  Ideally we
would want 2^13 and 2^14, and an agreement to use min(client_mfl,
server_mfl) rather than having the server dictate.  That might mean a
new extension, but I'm not sure.

> I can try to write the corresponding text for inclusion in the TLS 1.3
> draft. What is the process for submitting such text?

The spec is on github: https://github.com/tlswg/tls13-spec  You can
create a pull request.

However, I am going to suggest that this is a pretty big change.  It's
already late.  It might be better to create a new draft that revises
the maximum fragment length extension (or defines a better
replacement).

(As an aside, the success rate for RFC 6066 is pretty low in
retrospect, maybe there's an object lesson there.)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Thomas Pornin]

On Thu, Nov 24, 2016 at 09:10:00PM +, Fossati, Thomas (Nokia - GB)
wrote:
> I like your proposal, but I'm not convinced that overloading the
> semantics of an already existing extension when used in combination
> with a specific version of the protocol is necessarily the best
> strategy.  Besides, I'd like to be able to deploy a similar mechanism
> in 1.2.

Defining a new extension is certainly possible. However, it would then
require deciding on the intended behaviour when both that new extension
and the RFC 6066 extension are present.

Tentatively, one could try this:

  - The new extension documents the maximum record length supported
by whoever sends it. Encoding is as in RFC 6066: one byte of
value x for a maximum record plaintext length of 2^(x+8) bytes).
We extend that to the whole 1..8 range so that larger records
may be used by implementations who can afford them and obtain
some performance increase by doing so (actual maximum plaintext
length will be slightly less than 65535 bytes becose the length
header is 16-bit and there must be some room for the MAC).

  - If a client sends both the RFC 6066 extension and the new extension,
and the server supports the new extension, then the RFC 6066
extension is ignored and only the new extension is used. A server
MUST NOT send both extensions.

  - All implementations that support the extension MUST have the
ability to apply a shorter size limit than their maximum limit
(this is for _sending_ records).

  - The length sent by the server is the one that will be applied to
subsequent records on the connection, in both directions. This
applies to the whole connection, including subsequent handshakes
(renegotiations), unless both client and server send the new
extension again in a renegotiation (in which case the new length
appplies).

  - If using TLS 1.3, then the following extra rules apply:

 - All TLS 1.3 implementations MUST support the extension.

 - If the client does not send the new extension, then this is
   equivalent to the client sending the new extension with a
   value of 6 (i.e. maximum plaintext length is 2^14 = 16384 bytes).
   In particular, this allows the server to send the extension.

 - If the server does not send the new extension, then this is
   equivalent to the server sending the new extension with the
   same value as the one from the client. (So, if neither sends
   the extension, then the usual 16384-byte limit applies.)

  - If using TLS 1.2 or a previous version, then there is no implicit
usage:

 - The server MUST NOT send the new extension unless the client sent
   it.

 - The maximum plaintext limit shall be enforced only if the server
   sent the extension; that limit is the one defined by the server's
   extension.

 - If the client and/or the server does not send the extension, then
   the maximum plaintext length is the one that was in force at that
   point, i.e. 16384 bytes for a new connection, or whatever was
   used before the new handshake in case of renegotiation.

Some noteworthy points:

  * TLS 1.3 has no renegotiation, so the renegotiation behaviour is
for TLS 1.2 and previous. This avoids tricky issues with the
TLS 1.3 implicit behaviour in case of renegotiation.

  * A client SHOULD send the new extension in all ClientHello if it
is ready to use TLS 1.2 or previous, so that a non-1.3-aware
server may have the possibility to negotiate a shorter maximum
plaintext length.

  * The initial ClientHello may use records larger than what the server
is willing to accept, and before the server has any chance to
advertise its own maximum record size. However, since the initial
records are unprotected, implementations may be able to process
partial records, and thus could accept un-MACed records larger
than their incoming buffer (at least BearSSL can do that).


The "implicit" behaviour (both for client and server) with TLS 1.3 is a
way to make the extension free (with regards to network usage) in the
common case. It cannot be applied unless the extension support is made
mandatory for TLS 1.3. Making it mandatory is also an important feature,
since otherwise such an extension would likely remain unimplemented
by "big" clients (e.g. Web browsers).


Any comments?
I can try to write the corresponding text for inclusion in the TLS 1.3
draft. What is the process for submitting such text?


--Thomas Pornin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Michael Tuexen]

> On 24 Nov 2016, at 20:50, Thomas Pornin  wrote:
> 
> Hello,
> 
> I know that I am a bit late to the party, but I have a suggestion for
> the upcoming TLS 1.3.
> 
> Context: I am interested in TLS support in constrained architectures,
> specifically those which have very little RAM. I recently published a
> first version of an implementation of TLS 1.0 to 1.2, that primarily
> targets that kind of system ( https://www.bearssl.org/ ); a fully
> functional TLS server can then run in as little as 25 kB of RAM (and
> even less of ROM, for the code itself).
> 
> Out of these 25 kB, 16 kB are used for the buffer for incoming records,
> because encrypted records cannot be processed until fully received (data
> could be obtained from a partial record, but we must wait for the MAC
> before actually acting on the data) and TLS specifies that records can
> have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is
> directly related to that maximum fragment length.
> 
> There is a defined extension (in RFC 6066) that allows a client to
> negotiate a smaller maximum fragment length. That extension is simple
> to implement, but it has two problems that prevent it from being
> really usable:
> 
> 1. It is optional, so any implementation is free not to implement it,
>and in practice many do not (e.g. last time I checked, OpenSSL did
>not support it).
> 
> 2. It is one-sided: the client may asked for a smaller fragment, but
>the server has no choice but to accept the value sent by the client.
>In situations where the constrained system is the server, the
>extension is not useful (e.g. the embedded system runs a minimal
>HTTPS server, for a Web-based configuration interface; the client is
>a Web browser and won't ask for a smaller maximum fragment length).
> 
> 
> I suggest to fix these issues in TLS 1.3. My proposal is the following:
> 
> - Make Max Fragment Length extension support mandatory (right now,
>   draft 18 makes it "recommended" only).
> 
> - Extend the extension semantics **when used in TLS 1.3** in the following
>   ways:
> 
>   * When an implementation supports a given maximum fragment length, it
> MUST also support all smaller lengths (in the list of lengths
> indicated in the extension: 512, 1024, 2048, 4096 and 16384).
> 
>   * When the server receives the extension for maximum length N, it
> may respond with the extension with any length N' <= N (in the
> list above).
> 
>   * If the client does not send the extension, then this is equivalent
> to sending it with a maximum length of 16384 bytes (so the server
> may still send the extension, even if the client did not).
> 
>   Semantics for the extension in TLS 1.2 and previous is unchanged.
> 
> With these changes, RAM-constrained clients and servers can negotiate a
> maximum length for record plaintext that they both support, and such an
> implementation can use a small record buffer with the guarantee that all
> TLS-1.3-aware peers will refrain from sending larger records. With, for
> instance, a 2048-byte buffer, per-record overhead is still small (about
> 1%), and overall RAM usage is halved, which is far from negligible.
> 
> 
> RAM-constrained full TLS 1.3 is likely to be challenging (I envision
> issues with, for instance, cookies, since they can be up to 64 kB in
> length), but a guaranteed flexible negotiation for maximum fragment
> length would be a step in the right direction.
> 
> Any comments / suggestions ?
Can we extend this in a way that you can also increase the maximum
fragment length. So if the client requests a larger value and the
server is willing to do so, it can be used?

Best regards
Michael
> 
> Thanks,
> 
> 
>   --Thomas Pornin
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Hannes Tschofenig]

Hi Thomas,

your observations are in line with what we had noticed as well, see
Section 6 of
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00

Ciao
Hannes

On 11/24/2016 08:50 PM, Thomas Pornin wrote:
> Hello,
> 
> I know that I am a bit late to the party, but I have a suggestion for
> the upcoming TLS 1.3.
> 
> Context: I am interested in TLS support in constrained architectures,
> specifically those which have very little RAM. I recently published a
> first version of an implementation of TLS 1.0 to 1.2, that primarily
> targets that kind of system ( https://www.bearssl.org/ ); a fully
> functional TLS server can then run in as little as 25 kB of RAM (and
> even less of ROM, for the code itself).
> 
> Out of these 25 kB, 16 kB are used for the buffer for incoming records,
> because encrypted records cannot be processed until fully received (data
> could be obtained from a partial record, but we must wait for the MAC
> before actually acting on the data) and TLS specifies that records can
> have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is
> directly related to that maximum fragment length.
> 
> There is a defined extension (in RFC 6066) that allows a client to
> negotiate a smaller maximum fragment length. That extension is simple
> to implement, but it has two problems that prevent it from being
> really usable:
> 
>  1. It is optional, so any implementation is free not to implement it,
> and in practice many do not (e.g. last time I checked, OpenSSL did
> not support it).
> 
>  2. It is one-sided: the client may asked for a smaller fragment, but
> the server has no choice but to accept the value sent by the client.
> In situations where the constrained system is the server, the
> extension is not useful (e.g. the embedded system runs a minimal
> HTTPS server, for a Web-based configuration interface; the client is
> a Web browser and won't ask for a smaller maximum fragment length).
> 
> 
> I suggest to fix these issues in TLS 1.3. My proposal is the following:
> 
>  - Make Max Fragment Length extension support mandatory (right now,
>draft 18 makes it "recommended" only).
> 
>  - Extend the extension semantics **when used in TLS 1.3** in the following
>ways:
> 
>* When an implementation supports a given maximum fragment length, it
>  MUST also support all smaller lengths (in the list of lengths
>  indicated in the extension: 512, 1024, 2048, 4096 and 16384).
> 
>* When the server receives the extension for maximum length N, it
>  may respond with the extension with any length N' <= N (in the
>  list above).
> 
>* If the client does not send the extension, then this is equivalent
>  to sending it with a maximum length of 16384 bytes (so the server
>  may still send the extension, even if the client did not).
> 
>Semantics for the extension in TLS 1.2 and previous is unchanged.
> 
> With these changes, RAM-constrained clients and servers can negotiate a
> maximum length for record plaintext that they both support, and such an
> implementation can use a small record buffer with the guarantee that all
> TLS-1.3-aware peers will refrain from sending larger records. With, for
> instance, a 2048-byte buffer, per-record overhead is still small (about
> 1%), and overall RAM usage is halved, which is far from negligible.
> 
> 
> RAM-constrained full TLS 1.3 is likely to be challenging (I envision
> issues with, for instance, cookies, since they can be up to 64 kB in
> length), but a guaranteed flexible negotiation for maximum fragment
> length would be a step in the right direction.
> 
> Any comments / suggestions ?
> 
> Thanks,
> 
> 
>   --Thomas Pornin
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Maximum Fragment Length negotiation

[Fossati, Thomas (Nokia - GB)]

Hi Thomas,

We encountered the same issue and suggested something similar in [1] --
although not at the same level of detail as you below.

I like your proposal, but I'm not convinced that overloading the semantics
of an already existing extension when used in combination with a specific
version of the protocol is necessarily the best strategy.  Besides, I'd
like to be able to deploy a similar mechanism in 1.2.

So, why not simply allocating a new code-point for an extension with the
semantics you describe and make it available across different protocol
versions?

Cheers, t

[1] 
https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section-
6

On 24/11/2016 19:50, "TLS on behalf of Thomas Pornin"
 wrote:
>Hello,
>
>I know that I am a bit late to the party, but I have a suggestion for
>the upcoming TLS 1.3.
>
>Context: I am interested in TLS support in constrained architectures,
>specifically those which have very little RAM. I recently published a
>first version of an implementation of TLS 1.0 to 1.2, that primarily
>targets that kind of system ( https://www.bearssl.org/ ); a fully
>functional TLS server can then run in as little as 25 kB of RAM (and
>even less of ROM, for the code itself).
>
>Out of these 25 kB, 16 kB are used for the buffer for incoming records,
>because encrypted records cannot be processed until fully received (data
>could be obtained from a partial record, but we must wait for the MAC
>before actually acting on the data) and TLS specifies that records can
>have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is
>directly related to that maximum fragment length.
>
>There is a defined extension (in RFC 6066) that allows a client to
>negotiate a smaller maximum fragment length. That extension is simple
>to implement, but it has two problems that prevent it from being
>really usable:
>
> 1. It is optional, so any implementation is free not to implement it,
>and in practice many do not (e.g. last time I checked, OpenSSL did
>not support it).
>
> 2. It is one-sided: the client may asked for a smaller fragment, but
>the server has no choice but to accept the value sent by the client.
>In situations where the constrained system is the server, the
>extension is not useful (e.g. the embedded system runs a minimal
>HTTPS server, for a Web-based configuration interface; the client is
>a Web browser and won't ask for a smaller maximum fragment length).
>
>
>I suggest to fix these issues in TLS 1.3. My proposal is the following:
>
> - Make Max Fragment Length extension support mandatory (right now,
>   draft 18 makes it "recommended" only).
>
> - Extend the extension semantics **when used in TLS 1.3** in the
>following
>   ways:
>
>   * When an implementation supports a given maximum fragment length, it
> MUST also support all smaller lengths (in the list of lengths
> indicated in the extension: 512, 1024, 2048, 4096 and 16384).
>
>   * When the server receives the extension for maximum length N, it
> may respond with the extension with any length N' <= N (in the
> list above).
>
>   * If the client does not send the extension, then this is equivalent
> to sending it with a maximum length of 16384 bytes (so the server
> may still send the extension, even if the client did not).
>
>   Semantics for the extension in TLS 1.2 and previous is unchanged.
>
>With these changes, RAM-constrained clients and servers can negotiate a
>maximum length for record plaintext that they both support, and such an
>implementation can use a small record buffer with the guarantee that all
>TLS-1.3-aware peers will refrain from sending larger records. With, for
>instance, a 2048-byte buffer, per-record overhead is still small (about
>1%), and overall RAM usage is halved, which is far from negligible.
>
>
>RAM-constrained full TLS 1.3 is likely to be challenging (I envision
>issues with, for instance, cookies, since they can be up to 64 kB in
>length), but a guaranteed flexible negotiation for maximum fragment
>length would be a step in the right direction.
>
>Any comments / suggestions ?
>
>Thanks,
>
>
>   --Thomas Pornin
>
>___
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls
>


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Maximum Fragment Length negotiation

[Thomas Pornin]

Hello,

I know that I am a bit late to the party, but I have a suggestion for
the upcoming TLS 1.3.

Context: I am interested in TLS support in constrained architectures,
specifically those which have very little RAM. I recently published a
first version of an implementation of TLS 1.0 to 1.2, that primarily
targets that kind of system ( https://www.bearssl.org/ ); a fully
functional TLS server can then run in as little as 25 kB of RAM (and
even less of ROM, for the code itself).

Out of these 25 kB, 16 kB are used for the buffer for incoming records,
because encrypted records cannot be processed until fully received (data
could be obtained from a partial record, but we must wait for the MAC
before actually acting on the data) and TLS specifies that records can
have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is
directly related to that maximum fragment length.

There is a defined extension (in RFC 6066) that allows a client to
negotiate a smaller maximum fragment length. That extension is simple
to implement, but it has two problems that prevent it from being
really usable:

 1. It is optional, so any implementation is free not to implement it,
and in practice many do not (e.g. last time I checked, OpenSSL did
not support it).

 2. It is one-sided: the client may asked for a smaller fragment, but
the server has no choice but to accept the value sent by the client.
In situations where the constrained system is the server, the
extension is not useful (e.g. the embedded system runs a minimal
HTTPS server, for a Web-based configuration interface; the client is
a Web browser and won't ask for a smaller maximum fragment length).


I suggest to fix these issues in TLS 1.3. My proposal is the following:

 - Make Max Fragment Length extension support mandatory (right now,
   draft 18 makes it "recommended" only).

 - Extend the extension semantics **when used in TLS 1.3** in the following
   ways:

   * When an implementation supports a given maximum fragment length, it
 MUST also support all smaller lengths (in the list of lengths
 indicated in the extension: 512, 1024, 2048, 4096 and 16384).

   * When the server receives the extension for maximum length N, it
 may respond with the extension with any length N' <= N (in the
 list above).

   * If the client does not send the extension, then this is equivalent
 to sending it with a maximum length of 16384 bytes (so the server
 may still send the extension, even if the client did not).

   Semantics for the extension in TLS 1.2 and previous is unchanged.

With these changes, RAM-constrained clients and servers can negotiate a
maximum length for record plaintext that they both support, and such an
implementation can use a small record buffer with the guarantee that all
TLS-1.3-aware peers will refrain from sending larger records. With, for
instance, a 2048-byte buffer, per-record overhead is still small (about
1%), and overall RAM usage is halved, which is far from negligible.


RAM-constrained full TLS 1.3 is likely to be challenging (I envision
issues with, for instance, cookies, since they can be up to 64 kB in
length), but a guaranteed flexible negotiation for maximum fragment
length would be a step in the right direction.

Any comments / suggestions ?

Thanks,


--Thomas Pornin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls