Subject: [TLS] Alignment of the TLS/DTLS header

From: "Abhijit Choudhury (achoudhu)" <[email-masked]>
Date: Thu, 24 Jul 2008 19:49:46 -0700

Folks,
 
DTLS is being considered for HW implementation in ASICs, and
is often HW-accelerated in processors using crypto engines 
that can be used to perform DTLS encryption/decryption.
 
TLS, and hence DTLS, are possibly the only protocols that have
an odd number of bytes in the header. One thing I have consistently 
seen in HW and even in SW implementations of DTLS is that the 
13 byte DTLS header causes implementation challenges. Almost all
headers in the IP packet are 4-byte aligned.
 
For ASICs, having the 13-byte DTLS header misaligns the HW parsers
so that subsequent headers in application-data type packets are
harder to parse out. For processor based implementations, sometimes 
the 13-byte header results in additional copies, and reduced
performance.
 
Now that we are trying to update DTLS, should we consider padding 
out the 13 byte header to 16 bytes, so that it becomes 4-byte aligned ?
Even 2-byte alignment would be an improvement.
 
I believe this will have provide significant benefits to ASIC 
implementations, and will also make SW implementations more
efficient.
 
Just wanted to bring this up and see what other implementers think.
 
Regards,
Abhijit
 
______________________________________
Abhijit K. Choudhury 
Office of the CTO                     Work: (408) 525 8682
Wireless Networking Business Unit     Fax:  (408) 525 4283
Cisco Systems, Inc.                   Email: [email-masked] 
 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 25 Jul 2008 09:25:24 -0400

Makes sense to me.

On 7/24/08 22:49 PM, "Abhijit Choudhury (achoudhu)" <[email-masked]> wrote:

Folks,

For ASICs, having the 13-byte DTLS header misaligns the HW parsers
so that subsequent headers in application-data type packets are
harder to parse out. For processor based implementations, sometimes
the 13-byte header results in additional copies, and reduced performance.

Regards,
Abhijit

______________________________________
Abhijit K. Choudhury
Office of the CTO                     Work: (408) 525 8682
Wireless Networking Business Unit     Fax:  (408) 525 4283
Cisco Systems, Inc.                   Email: [email-masked] <mailto:[email-masked]>

--
Regards,
Uri
<Disclaimer>

---

From: Mike <[email-masked]>
Date: Fri, 25 Jul 2008 07:28:56 -0700

If you're going to make incompatible changes to the header, then I
would suggest instead of adding three bytes, remove the content type
from the header and protect it along with the plain text.  This will
make the header 12 bytes which gives you 4-byte alignment.

Now why would you want to hide the content type?  If you do that,
then you can add a new content type, "junk", which is simply thrown
away by the receiver, but which gives applications the ability to
thwart traffic analysis.  With a public content type, every packet
must mean something; if it's private an attacker won't have a clue
what is real data and what is not.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 07:43:04 -0700

At Thu, 24 Jul 2008 19:49:46 -0700,
> Just wanted to bring this up and see what other implementers think.

Do you have some estimates of the magnitude of the expected
performance benefits?

Thanks,
-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 08:46:24 -0700

At Fri, 25 Jul 2008 07:28:56 -0700,
> what is real data and what is not.

This gets at the question of what's important in terms of alignment,
since that makes the *ciphertext* aligned, but means that the 
part of the plaintext that has to be processed by the next
level protocol is unaligned. So, what are we trying to optimize
for?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 09:00:50 -0700

> what is real data and what is not.

It's worth noting that DTLS (thought not TLS) has a 
way to provide this feature without changing the bits on
the wire: generate packets with bogus MACs.

-Ekr

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 26 Jul 2008 23:00:22 +1200

"Abhijit Choudhury (achoudhu)" <[email-masked]> writes:

> [...]

I've argued this in the past for the annoyingly-sized 5-byte TLS header
(this was pre-DTLS), in particular the removal of the totally unnecessary
version-number field would make it a nice 32-bit aligned value.
Unfortunately the proposal didn't meet with much enthusiasm :-(.

Peter.

---

From: Michael Tüxen <[email-masked]>
Date: Sat, 26 Jul 2008 15:12:58 +0200

> version-number field would make it a nice 32-bit aligned value.
Isn't the version number used to distinguish between TLS and DTLS?

However, making the header 32-bit aligned seems a good idea from my
perspective.

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 27 Jul 2008 03:29:42 +1200

> Isn't the version number used to distinguish between TLS and DTLS?

I don't have access to the DTLS spec at the moment but at least for TLS it's
entirely redundant for anything after the handshake, since it's just a
constant value that has to be copied into each header but serves no actual
purpose.

> However, making the header 32-bit aligned seems a good idea from my

Given all of the other incompatible changes made in newer versions of TLS,
it'd certainly be a comparatively trivial one to get rid of the redundant
version info and make it a single 32-bit value.

Peter.

---

From: Michael Tüxen <[email-masked]>
Date: Sat, 26 Jul 2008 18:20:49 +0200

> constant value that has to be copied into each header but serves no  
TLS (RFC 4346) uses
        struct {
            ContentType type;
            ProtocolVersion version;
            uint16 length;
            opaque fragment[TLSPlaintext.length];
        } TLSPlaintext;
and states
This document describes TLS Version 1.1, which uses the version { 3, 2 }

DTLS (RFC 4347) uses
        struct {
          ContentType type;
          ProtocolVersion version;
          uint16 epoch;                                    // New field
          uint48 sequence_number;                          // New field
          uint16 length;
          opaque fragment[DTLSPlaintext.length];
        } DTLSPlaintext;
and states

This document describes DTLS Version 1.0, which uses the
version { 254, 255 }.
The version value of 254.255 is the 1's complement of DTLS
Version 1.0. This maximal spacing between TLS and DTLS version
numbers ensures that records from the two protocols can be
easily distinguished.

BTW: When omitting the version from the TLS header it has a length
of 3 bytes. So do you want to add one byte padding? Or am I missing
something?

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 27 Jul 2008 04:29:44 +1200

> of 3 bytes. So do you want to add one byte padding? Or am I missing

Either that or use a 24-bit length, the mishmash of 16-bit and 24-bit
lengths is another TLS annoyance :-).

(By "use a 24-bit length" I really meant "use a 16-bit length and always
set the high byte to zero so it takes 24 bits", so it's the same as your
suggestion of using padding).

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 26 Jul 2008 19:47:50 +0300

> harder to parse out. 
Why is this? Probably if the design is based on an ASIC that parses IP
packets, it will not be optimal, but can't a design specifically for TLS
parse those packets optimally?

> For processor based implementations, sometimes 
I cannot understand this. Could you please elaborate?

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 Jul 2008 21:28:46 -0700

At Sat, 26 Jul 2008 19:47:50 +0300,
> I cannot understand this. Could you please elaborate?

After thinking about this for a while, this seems like a pretty
significant change to make to DTLS, especially given that I don't
expect us to change TLS 1.2 at this point, so hardware will need 
to support the unaligned version anyway.

I'd prefer not to do this absent some pretty compelling 
data indicating that it makes a big performance difference.

-Ekr