Subject: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt

From: [email-masked]
Date: Fri, 11 Jun 2010 20:45:11 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the IETF.

	Title           : Transport Layer Security (TLS) Extensions: Extension Definitions
	Author(s)       : D. Eastlake 3rd
	Filename        : draft-ietf-tls-rfc4366-bis-09.txt
	Pages           : 31
	Date            : 2010-06-11

This document provides specifications for existing TLS extensions. It
is a companion document for the TLS 1.2 specification [RFC5246]. The
extensions specified are server_name, max_fragment_length,
client_certificate_url, trusted_ca_keys, truncated_hmac, and
status_request.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 12 Jun 2010 16:10:02 +0200

> client_certificate_url, trusted_ca_keys, truncated_hmac, and

It has been mentioned before, but I think its worthwhile to bring it up
again. The "Maximum Fragment Length" extension only allows setting a
fragment length that is lower than 2^14... Why not allow larger sizes
than that?

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 13 Jun 2010 00:07:43 +0300

> fragment length that is lower than 2^14... Why not allow larger sizes

I haven't seen any earlier discussion related to this, so consider me as an outsider. However, the document is a companion document for the TLS 1.2 specification and the TLS 1.2 specification says:

      The length (in bytes) of the following TLSPlaintext.fragment.  The
      length MUST NOT exceed 2^14.

I think overriding the specification with this extension would be a really bad idea, and even then the hard limit of 2^16 would apply, since fragment length is an uint16.

I have no exact information about where 2^14 the limit itself is coming from (it dates all the way back to SSL 3.0), but I can imagine it has something to do with values 2^15 and up being negative if signed 16-bit integers are used. Therefore bad implementations might break, in case fragment length is 2^15 or larger and they are using signed integer instead of unsigned. Specifying it as lower than 2^14 is a safe bet, since even with all the headers and extra payload it can't really go over the 2^15 limit.

Juho

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 13 Jun 2010 20:11:40 +1200

Nikos Mavrogiannopoulos <[email-masked]> writes:

>I have no exact information about where 2^14 the limit itself is coming from 
>(it dates all the way back to SSL 3.0), but I can imagine it has something to 
>do with values 2^15 and up being negative if signed 16-bit integers are used. 

It may also have been because it's a convenient upper bound for memory 
buffers, particularly in embedded systems.  There's an awful lot of SSL 
running in little controller boards for various devices, having to allocate 
potentially 2 x 64kB buffers (the limit for 16-bit lengths) instead of 2 x 
16kB would have been a deal-breaker for some of them.  In addition, as you
say, on 16-bit systems (some of which are still in use today, again in 
embedded devices) you run into risky conditions once you get close to 2^15.

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 13 Jun 2010 10:22:46 +0200

> embedded devices) you run into risky conditions once you get close to 2^15.

This is not really a stopper. Since it is being negotiated it should be
obvious that those clients will accept the default or less. The
intention is to give choice to more capable clients and servers.

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 13 Jun 2010 12:01:18 +0300

> intention is to give choice to more capable clients and servers.

I still don't see a big benefit in making the maximum fragment length 64kB instead of 16kB, since all implementations have to be able to fall back to the 16kB anyway, and handshake messages have maximum length of 16MB so the fragmentation has to be handled nevertheless. 

The benefit of having a fragment length smaller than 2^14 seems quite clear to me. First is what Peter mentioned, the maximum TLSRecord size directly affects the required I/O buffers size that need to be allocated no matter what. Handshake message buffers still might be larger than that, but they can be allocated larger when needed and the implementation can fail gracefully if a handshake message is too large.

Another benefit comes from DTLS, where TLSRecords themselves need to be fragmented in order to fit inside a single IP packet. If the implementation can negotiate a fragment length with a max_fragment_length extension, it doesn't have to be able to handle the double fragmentation (first fragment handshake, then encrypt, then fragment the encrypted data).

If the fragment length is increased from 16kB to 64kB, I can only see a benefit of 3*(5+IV+padding+MAC) bytes per 64kB. That is at most 927 bytes with current implementations, more likely less than 200 bytes since adding 256 bytes of padding is a waste. It would save less than 0,4-1,5% of bandwidth, and if the current implementations don't implement the extension just because they have expected the value not to exceed 2^14 before, it would make all the benefits mentioned earlier void as well.

So is your motivation behind making it larger what I just mentioned above or maybe something else? Since I would like to know if I've missed something important or if this is just a disagreement on the mentioned feature being useful or not.

Juho

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Sun, 13 Jun 2010 12:16:47 +0300

> Another benefit comes from DTLS, where TLSRecords themselves need to be fragmented in order to fit inside a single IP packet. If the implementation can negotiate a fragment length with a max_fragme…

I should get rid of the bad habit of reviewing documents after sending, but I remembered the DTLS specification wrong. The TLSRecords can't be fragmented, but instead the mentioned process is simply "fragment handshake" -> "encrypt". That's my bad, this argument is not valid.

However the draft itself says "memory constraints among some clients, and bandwidth constraints" which both seem to be understandable. With a limited bandwidth small TLSRecord fragments is a good thing, because the data can be processed faster instead of in very large chunks.

Juho

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 13 Jun 2010 21:32:11 -0700

At this point I don't want to open up other sections of the document for
changes as it is fairly far along and we need to publish the document. I
don't see overwhelming support to change it.  

Thanks,

Joe
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nikos Mavrogiannopoulos
> Sent: Saturday, June 12, 2010 7:10 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [TLS] I-D Action:draft-ietf-tls-rfc4366-bis-09.txt
> 
> > This draft is a work item of the Transport Layer Security Working
Group
> of the IETF.
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 14 Jun 2010 09:46:18 +0200

> I still don't see a big benefit in making the maximum fragment length 64kB instead of 16kB, since all implementations have to be able to fall back to the 16kB anyway, and handshake messages have ma…

I don't understand your point. Implementations that want to support
could support it (i.e. when implementing for a high bandwidth tunnel),
and others can use the 16kb limit. Being able not to use it is an
advantage not a limitation.

> Another benefit comes from DTLS, where TLSRecords themselves need to be fragmented in order to fit inside a single IP packet. If the implementation can negotiate a fragment length with a max_fragme…

Then it shouldn't negotiate it. Isn't it obvious? The extension is for
applications that require more bandwidth and are not running on 8 or
16 bit cpus. This is an extension you use it when you need it, not
when you don't.

> So is your motivation behind making it larger what I just mentioned above or maybe something else? Since I would like to know if I've missed something important or if this is just a disagreement on…

The save is not on data sent but on processing speed. Decryption and
encryption today is done in hardware (several embedded systems have a
crypto coprocessor) so the bottleneck is on processing those
fragments. The larger they are the less they are processed, the higher
the bandwidth. (check what happens to ATM today with the fixed 53 byte
payload, everybody tries to do reassembly in hardware otherwise the
performance is poor. 16kb is not 53 bytes but it's close :)

regards,
Nikos

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Mon, 14 Jun 2010 11:23:32 +0300

> advantage not a limitation.

Of course, and I also find it strange that 2^13 is left out from the 
specification, since it's less than 2^14. I'm mainly questioning if 
raising it to 2^15 is much help (it's just 16kB vs 32kB there). In 
practice you can't raise it to 2^16 because of the IV, padding and MACs, 
and defining numbers between 2^15 and 2^16 feels a bit ugly as well and 
might require fixing later if there's more additional payload defined 
that wasn't known during the specification. All implementations can work 
around these naturally, but from specification point of view things that 
might have to be removed later shouldn't be added. Maybe adding 32kB and 
48kB would be a nice middle ground, but it would be nice to have some 
proof of the benefits and performance improvement.

> 16 bit cpus. This is an extension you use it when you need it, not

Well, the extension specification itself says it's for applications that 
have memory and bandwidth limitations. With the modification of 
accepting values larger than 2^14 it could be modified to also work on 
applications that require more bandwidth, which is your point I guess.

> performance is poor. 16kb is not 53 bytes but it's close :)

I don't deny this, larger chunks of data are always easier to process, 
especially if the process can be done in parallel. One of the biggest 
bottlenecks in TLS decryption performance I can see, is the stream and 
CBC block ciphers requiring decryption before the MAC calculation can be 
initiated. Therefore, if the decryption and encryption performance is 
really important, I'd rather concentrate on getting the AES-GCM and 
AES-CCM ciphers into wider use in TLS. After that the benefits of having 
a larger record fragment length can be discussed, since these ciphers 
are probably the ones benefiting from it the most. The authenticating 
ciphers might be hard to get into mainstream use before the stable 
versions of free software implementations catch up and start to support 
them as well, though.

Juho

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Jun 2010 14:57:46 +0200 (MEST)

> 	Filename        : draft-ietf-tls-rfc4366-bis-09.txt

What irritates me slightly about the document style is the
mixture of the term "SHALL" and "MUST".  While its true that
rfc2119 allows both terms, I would prefer IETF documents to
use MUST/MUST NOT over SHALL/SHALL NOT and avoid a mixture,
unless there is a rationale behind it, like adopting text as-is
from other standards/standarization bodies.

-Martin

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 14 Jun 2010 09:08:36 -0400

It seems to me that Nikos is making a perfect point.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Mon, 14 Jun 2010 16:26:46 +0300

> It seems to me that Nikos is making a perfect point.

Don't get me wrong, I'm mostly curious about the motivation behind 
adding larger values, because I think the benefit of it seems to be very 
small and originally I hadn't taken hardware decoding into 
consideration. After this discussion I think adding something like 2^13, 
2^15 and maybe (2^14 + 2^15) to the extension enum in question might be 
a good idea. Could add a specific notion that the implementation has to 
take care that it can support large fragments in case a value larger 
than 2^14 is accepted, because it is not required by the original 
specification. More efficient hardware decoding should be mentioned in 
motivation for accepting larger values as well, since now it only says 
memory and bandwidth constraings.

Not that it would be up to me to decide. :)

Juho

---

From: <[email-masked]>
Date: Mon, 14 Jun 2010 16:47:10 +0200

Joseph Salowey wrote:

> At this point I don't want to open up other sections of the document
> for changes as it is fairly far along and we need to publish the
> document.  I don't see overwhelming support to change it. 

I agree, especially since we would need to define a new extension;
this text seems to prevent adding new values in backwards-compatible
manner:

   If a server receives a maximum fragment length negotiation request
   for a value other than the allowed values, it MUST abort the
   handshake with an "illegal_parameter" alert. 

Best regards,
Pasi

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 14 Jun 2010 11:17:49 -0400

Not too surprisingly rfc4366-bis derives from rfc4366 which had mixed use of
SHALL and MUST.

Donald
=============================
Donald E. Eastlake 3rd
155 Beaver Street
Milford, MA 01757 USA
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Jun 2010 19:06:57 +0200 (MEST)

> Not too surprisingly rfc4366-bis derives from rfc4366 which had mixed use of

This draft is supposed to be a successor to rfc4366, so "fixing"
a confusing mixture of SHALL&MUST into a consistent MUST throughout
seems like the correct thing to do on a document update.

Btw. I liked the original section numbering of rfc-4366 better,
where all extensions appeared as subsections of section 3.

The old numbering scheme would also match the new Security Considerations
substructure more naturally.  

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 15 Jun 2010 18:26:49 +1200

=?UTF-8?B?SnVobyBWw6Row6QtSGVydHR1YQ==?= <[email-masked]> writes:

>One of the biggest bottlenecks in TLS decryption performance I can see, is
>the stream and CBC block ciphers requiring decryption before the MAC
>calculation can be initiated. Therefore, if the decryption and encryption
>performance is really important, I'd rather concentrate on getting the AES-
>GCM and AES-CCM ciphers into wider use in TLS.

Why not allow encrypt-then-MAC to be negotiated in an extension?  This is a
really trivial change to existing code (arguably it could have been done for
TLS 1.2, since that incompatibly changes lots of the other crypto as well),
and means it'd follow encrypt-then-MAC best practice for security.

Peter.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 15 Jun 2010 09:37:27 +0300

> and means it'd follow encrypt-then-MAC best practice for security.

I think this sounds like a good idea. I always found it weird that TLS, since 1.1, mentions in its documentation that encrypt-then-authenticate is best practice, but we just happen to use authenticate-then-encrypt and there's nothing you can do about it.

Juho

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Jun 2010 09:52:16 +0200

On Mon, Jun 14, 2010 at 10:23 AM, Juho Vähä-Herttua <[email-masked]> wrote:

> bottlenecks in TLS decryption performance I can see, is the stream and CBC
> block ciphers requiring decryption before the MAC calculation can be
> initiated. Therefore, if the decryption and encryption performance is really
> important, I'd rather concentrate on getting the AES-GCM and AES-CCM ciphers
> into wider use in TLS.

This is orthogonal to what I proposed. What I say provides advantage
irrespective to the ciphersuite used. And in reality the faster the
ciphersuite is, the more the need for larger payloads, that is because
the bottleneck now becomes processing and not encryption.

regards,
Nikos

---

From: "t.petch" <[email-masked]>
Date: Tue, 15 Jun 2010 09:25:40 +0200

How may an application send a 64kbyte (less headers) message over DTLS, assuming
that the substrate is UDP and that UDP can carry 64kbyte datagrams without
fragmentation?

A usually reliable source has surprised me on two counts:

First, I am told that when rfc4347-bis says
"As in TLS
       1.2, the length should not exceed 2^14.
"
then that is the authors' way of saying
"As in TLS 1.2, the length MUST NOT exceed 2^14."
which I had not guessed.

Second, that DTLS will break up the message into fragments of 2**14 or less but
will then place them in a single UDP datagram so that they will transit the
network as one, and can be safely reassembled at the far end.

Thoughts?

Tom Petch

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 15 Jun 2010 12:06:46 +0300

> that the substrate is UDP and that UDP can carry 64kbyte datagrams without

This sounds like another argument for max_fragment_length extension 
allowing lengths larger than 2^14...

> "As in TLS 1.2, the length MUST NOT exceed 2^14."

That wording is indeed confusing and should probably be changed, TLS 1.2 
uses MUST NOT so a "should not" is not "as in TLS 1.2". With current 
wording I wouldn't recommend exceeding 2^14 length, since it is quite 
likely to break with some implementations.

> network as one, and can be safely reassembled at the far end.

The specification says: "Multiple DTLS records may be placed in a single 
datagram. They are simply encoded consecutively." So in case of 64kB 
datagrams there can be either multiple complete records (with fragments 
of 2^14 or less) included in a single datagram or each record having its 
own datagram, in the receiving end both cases should be handled. It's 
basically the same as in TLS 1.2 where large handshake messages need to 
be fragmented into fragments of 2^14 or less and sent consecutively.

This is just my interpretation, but I think the specification is quite 
clear on this, and your source is probably correct.

Juho

---

From: Michael Tüxen <[email-masked]>
Date: Tue, 15 Jun 2010 15:29:28 +0200

On Jun 15, 2010, at 11:06 AM, Juho Vähä-Herttua wrote:

> This sounds like another argument for max_fragment_length extension allowing lengths larger than 2^14...
> 
> That wording is indeed confusing and should probably be changed, TLS 1.2 uses MUST NOT so a "should not" is not "as in TLS 1.2". With current wording I wouldn't recommend exceeding 2^14 length, since it is quite likely to break with some implementations.
> 
> The specification says: "Multiple DTLS records may be placed in a single datagram. They are simply encoded consecutively." So in case of 64kB datagrams there can be either multiple complete records (with fragments of 2^14 or less) included in a single datagram or each record having its own datagram, in the receiving end both cases should be handled. It's basically the same as in TLS 1.2 where large handshake messages need to be fragmented into fragments of 2^14 or less and sent consecutively.
DTLS will not fragment any user data. So the application is limited by the path mtu.
When running DTLS/SCTP, SCTP announces a MTU of 2**14 and uses its own fragmentation,
but for UDP this is not possible.
To use user messages larger than 2^14, you need a link layer with an MTU of 2^14 or
higher. Do you?

Best regards
Michael
> 
> This is just my interpretation, but I think the specification is quite clear on this, and your source is probably correct.
> 
> 
> Juho
>

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Tue, 15 Jun 2010 14:22:03 -0400

> and means it'd follow encrypt-then-MAC best practice for security.

Strictly speaking there is a difference between authenticating the plaintext
and then encrypting it, and authenticating the ciphertext.

In practice, particularly for protocols such as TLS (and SNMP where
encrypt-then-authenticate was done first in IETF), it should be OK.

---

From: "t.petch" <[email-masked]>
Date: Wed, 16 Jun 2010 10:06:35 +0200

----- Original Message -----
From: "Michael Tüxen" <[email-masked]>
Sent: Tuesday, June 15, 2010 3:29 PM

On Jun 15, 2010, at 11:06 AM, Juho Vähä-Herttua wrote:

> That wording is indeed confusing and should probably be changed, TLS 1.2 uses
MUST NOT so a "should not" is not "as in TLS 1.2". With current wording I
wouldn't recommend exceeding 2^14 length, since it is quite likely to break with
some implementations.
> The specification says: "Multiple DTLS records may be placed in a single
datagram. They are simply encoded consecutively." So in case of 64kB datagrams
there can be either multiple complete records (with fragments of 2^14 or less)
included in a single datagram or each record having its own datagram, in the
receiving end both cases should be handled. It's basically the same as in TLS
1.2 where large handshake messages need to be fragmented into fragments of 2^14
or less and sent consecutively.

DTLS will not fragment any user data. So the application is limited by the path
mtu.
When running DTLS/SCTP, SCTP announces a MTU of 2**14 and uses its own
fragmentation,
but for UDP this is not possible.
To use user messages larger than 2^14, you need a link layer with an MTU of 2^14
or
higher. Do you?

<tp>

I am assuming UDP, no SCTP, and a link layer MTU of at least 64kbyte, with a a
message something under 64kbyte to allow for potentially multiple DTLS headers
to still fit the original application message in a single UDP datagram.

(In passing, I would love to see documentation on DTLS implementations but what
is publicly available seems scarce to non-existent).

Tom Petch

</tp>

Best regards
Michael
>
> This is just my interpretation, but I think the specification is quite clear
on this, and your source is probably correct.

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Jun 2010 11:59:12 +0200

> to still fit the original application message in a single UDP datagram.
Haven't seen a link with an MTU of 64KByte yet, but at least in the future it
might happen and Matt would love it... 
> is publicly available seems scarce to non-existent).
Our experience with the OpenSSL implementation of DTLS is pretty good, at least
after applying the patches available from
http://sctp.fh-muenster.de/
which mostly are integrated in the releases.

Best regards
Michael

---

From: <[email-masked]>
Date: Wed, 16 Jun 2010 13:07:09 +0200

Michael Tüxen wrote:

> DTLS will not fragment any user data. So the application is limited
> by the path mtu.  When running DTLS/SCTP, SCTP announces a MTU of
> 2**14 and uses its own fragmentation, but for UDP this is not
> possible.  To use user messages larger than 2^14, you need a link
> layer with an MTU of 2^14 or higher. Do you?

No, you can also use IP layer fragmentation (although that's not such
a great idea performance-wise if you're running over general
Internet -- instead of, say, inside a data center).

Best regards,
Pasi

---

From: Michael Tüxen <[email-masked]>
Date: Wed, 16 Jun 2010 13:33:18 +0200

> Internet -- instead of, say, inside a data center).
I think IP fragmentation should be avoided, that is why RFC 4347 states

   If the application
   attempts to send a record larger than the MTU, the DTLS
   implementation SHOULD generate an error, thus avoiding sending a
   packet which will be fragmented.

If you really need to send user messages larger then the MTU you should
use TCP or SCTP as a transport protocol.

Best regards
Michael

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 18 Jun 2010 01:40:30 +1200

=?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= <[email-masked]> writes:

>I think this sounds like a good idea. I always found it weird that TLS, since
>1.1, mentions in its documentation that encrypt-then-authenticate is best
>practice, but we just happen to use authenticate-then-encrypt and there's
>nothing you can do about it.

I've now had a couple of people express interest in this, is there some
general new-extensions draft in the works to add this to, or should I do a new
draft?  Unfortunately it's come just too late for tacking onto draft-ietf-tls-
rfc4366-bis, sigh, and it's such a trivial change that 90% of a draft for it
is going to be taken up with boilerplate.

Peter.