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 +0000, 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<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
