Subject: [TLS] Encryption of TLS 1.3 content type

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 25 Jul 2014 17:37:29 +0000

At the interim meeting on July 20, 2014 there was general consensus to support the encryption of TLS 1.3 content type.  The favored approach was to remove the content type and version from the TLS record layer header and add the content type to the encrypted data.   The proposal is to update the draft to document this approach and try to run some tests to see if this causes much grief with middle boxes.  If you object to this proposal please respond to the list by Friday, August 01, 2014.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Jul 2014 16:57:35 -0400

Hi.

I believe that changing the 5-byte record header will cause us trouble. Passive IDS/IPS devices follow TLS streams to detect certain attacks. They will cut connections. I also believe that it is impossible to “run some tests” because there are literally dozens of different such middleboxes, with multiple software/firmware versions available for each type.

I therefore support leaving the 5-byte header as it is, fixing the ContentType value to 23 for all encrypted records, and having another contentType byte within the encrypted record.

Yoav

On Jul 25, 2014, at 1:37 PM, Joseph Salowey (jsalowey) <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Fabrice Gautier <[email-masked]>
Date: Fri, 25 Jul 2014 14:05:58 -0700

I also object this proposal

I'm not too familiar with IETF process, but shouldn't we have test
results first before we actually update the draft ?
I know its just a draft and it can be probably be changed back if the
test results are bad, but it seems it might be an uphill battle then.

Also I haven't seen a discussion of what the tests would be, or what
would be considered acceptable results. I didn't think the IETF
process usually involve testing in any formal manner. I'm assuming
that this would be up to individual contributors to test this with
their own TLS 1.3 draft implementations and then raise issues if they
appear later ?

If thats correct, it seems that this proposal is to update the draft
and see if anybody complains later based on actual tests.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2014 14:11:33 -0700

On Fri, Jul 25, 2014 at 1:57 PM, Yoav Nir <[email-masked]> wrote:

> Hi.
>
> I believe that changing the 5-byte record header will cause us trouble.
> Passive IDS/IPS devices follow TLS streams to detect certain attacks. They
> will cut connections. I also believe that it is impossible to “run some
> tests” because there are literally dozens of different such middleboxes,
> with multiple software/firmware versions available for each type.
>
> I therefore support leaving the 5-byte header as it is, fixing the
> ContentType value to 23 for all encrypted records, and having another
> contentType byte within the encrypted record.

Yoav,

The tests I had in mind were having browsers form connections back to
some central server and measure how it works. That's not perfect, but
it lets us test with a large corpus.

-Ekr

> > At the interim meeting on July 20, 2014 there was general consensus to
> support the encryption of TLS 1.3 content type.  The favored approach was
> to remove the content type and version from the TLS record layer header and
> add the content type to the encrypted data.   The proposal is to update the
> draft to document this approach and try to run some tests to see if this
> causes much grief with middle boxes.  If you object to this proposal please
> respond to the list by Friday, August 01, 2014.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 26 Jul 2014 10:43:19 -0700

This is a change with no rationale: the content type leaks extremely
limited information. It complicates implementations that wish to keep
a high degree of codepath similarity between TLS 1.2 and TLS 1.3.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Colm MacCárthaigh <[email-masked]>
Date: Sat, 26 Jul 2014 10:59:15 -0700

Leaking alert messages has been a recurring theme common to several
attacks; hindering a MITM's ability to discern alert messages seems
like a rational rationale.

-- 
Colm

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Jul 2014 10:55:53 +0200

> like a rational rationale.

Are there any pointers to these attacks? Will these attacks be countered
with such a change? I believe not as alert messages consist of only two
bytes and will be distinct from any other higher protocol messages
transferred by the TLS record protocol. Unless TLS 1.3 intended to
include a length hiding mechanism I see this change as unnecessary and I
agree with Watson on that.

If we cannot avoid changes to TLS 1.3 charter, I believe that any new
proposal comes with a concrete case for it and associated costs of
implementing vs not-implementing. The initial agreement was for a small
revision to TLS (even though I didn't agree on that), and that is now
used as a vehicle to push unrelated to the charter major changes with no
planning whatsoever. I'm afraid in the end the result will be an
ISO-type of protocol.

regards,
Nikos

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Jul 2014 13:52:22 +0300

> agree with Watson on that.

While no definite decisions were made, there was a positive response to the idea of allowing arbitrary length padding to the plaintext in all encrypted records, which can be used to hide alert messages. 

Of course, non-fatal alerts are (1) rare, and (2) not always treated as such, so it’s easy to spot the alert record, because it’s the one before the FIN or RST. In DTLS alerts are mostly non-fatal, so it makes more sense.

So on balance, +1.

> planning whatsoever. 

Our charter does say “Develop a mode that encrypts as much of the handshake as is possible”

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 28 Jul 2014 09:57:39 -0400

On 07/28/2014 04:55 AM, Nikos Mavrogiannopoulos wrote:
> Unless TLS 1.3 intended to include a length hiding mechanism
> I see this change as unnecessary and I agree with Watson on that.

One of the motivations to support this change is due to the possibility
of length-hiding within TLS (which might be indicated by a new
content-type), as well as leaving the door open to other future content
types that might or might not be sensitive.  It was a design error to
ever leave this information in the clear in the first place, afaict.  We
should fix it.

If we have to throw a dummy byte (or two, if we need to include the
version) per (D)TLS record to appease middleboxes, we can do that, but
that should be strictly for the sake of working around the ossified
network stack.

	--dkg

---

From: [email-masked] (Martin Rex)
Date: Mon, 28 Jul 2014 16:39:50 +0200 (CEST)

I also object to the removal of the ContentInfo from the outer
TLS record protocol.  I'm not aware of the slightest rationale for
this severe backwards incompatibility, that will not just break
middle-boxes, but also applications that parse TLS records for the
purpose of non-blocking operation.

> like a rational rationale.

Which attacks do you have in mind?  I'm actually not aware of any.

The Bleichenbacher PKCS#1 decryption oracle happened during the
cleartext phase (so this doesn't apply here), and while the
CBC guessing happened in the encrypted phase, the attacker was
in posession of the decryption key, could properly decrypt the
alert, and use it to distinguish decryption failure from mac failure
alerts.

So in both situations, content hiding would not have had the slightest
impact on these attacks.

-Martin

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jul 2014 07:54:00 -0700

On Mon, Jul 28, 2014 at 1:55 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> transferred by the TLS record protocol.

This is not the case. Firstly, even with a stream cipher it doesn't
distinguish the message from a 2 byte application data message. But
most ciphers are block ciphers, and so the true length is fuzzed by
about an order of magnitude.

-- 
Colm

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Jul 2014 17:05:52 +0200

> ever leave this information in the clear in the first place, afaict.  We

I don't think so. The privacy concerns over the content type are
minuscule(*) and the debugging information provided by them is priceless
to a network engineer.

(*): I understand the trend of encrypt as much as possible -indicated by
the charter entry on handshake protocol and extended here to the record
protocol-, but what is really the threat here?

> that should be strictly for the sake of working around the ossified

Such moves contribute to the complexity of TLS implementations and I
don't see any immediate privacy enhancement here to justify that (note
that TLS has different goals to TOR).

Nevertheless, if we really need a TLS redesign to address new goals and
requirements then let's just do that, name it TLS 2.0, gather all the
requirements and design it from ground up, not with arbitrary
un-coordinated actions during a maintenance release that has specific
charter goals (and record layer modification was not in them). Or if
that's not possible the interesting parties should proceed with a
separate contribution that provides length hiding and content hiding if
you consider that important.

regards,
Nikos

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 28 Jul 2014 11:08:20 -0400

> purpose of non-blocking operation.

Parsing TLS records is still possible, since the length field will be
present.

I tried to highlight your concern about non-blocking applications to the
TLS WG during the interim meeting last Sunday, but clearly failed to do
it justice because none of those attending the interim (including
myself) appeared to understand what specific toolchain you were trying
to preserve.

Can you provide more details?  Applications that just look at the raw
TLS records will still be able to tell when the communication shifts
from cleartext to non-cleartext, but they should not be able to see more
than that about the ciphertext.

In what case is this a problem?

	--dkg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 28 Jul 2014 17:14:16 +0200

> about an order of magnitude.

On the contrary, all _new_ ciphers are stream (GCM, CCM) and every
future AEAD cipher will be a stream one (due to limitations of the AEAD
construction in TLS). Furthermore, even if you assume that only AES-CBC
is going to be used, do you really consider a 16-byte alert packet
fuzzed? Do you know many application protocols that transfer such short
packets?

regards,
Nikos

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 28 Jul 2014 15:25:26 +0000

> fuzzed? Do you know many application protocols that transfer such short

[ Note, I far from convinced that encrypting the record type is useful ]

Yes, some application application protocols do send short messages,
for example SMTP an server may reply "250 2.0.0 OK\r\n".  However,
(fatal) alerts often terminate the connection and are easily
distinguished from routine traffic.

In chatty protocols, like SMTP, TLS masks the specific content,
but not the overall flow or size of messages.  One can often tell
which application data messages carry "EHLO", "MAIL", "RCPT", "DATA"
and the message payload, despite the use of TLS.  The attacker does
not learn very much, but may be able to estimate the recipient
count, even with ESMTP PIPELINING and of course can estimate the
message size fairly well.

Defending against traffic analysis is very difficult, and I don't
think that TLS can (or should attempt to) do the job.

-- 
	Viktor.

---

From: Brian Sniffen <[email-masked]>
Date: Mon, 28 Jul 2014 11:35:04 -0400

Yoav Nir <[email-masked]> writes:

> While no definite decisions were made, there was a positive response
> to the idea of allowing arbitrary length padding to the plaintext in
> all encrypted records, which can be used to hide alert messages.

It's not clear to me that it can be used to hide alert messages, or the
structure of the interaction at that level at all.  Can you show me a
model of a TLS 1.3 client state machine and a TLS 1.3 server state
machine such that they both do padding, send messages on a clock, and
otherwise take best-understood precautions against passive
analysis---and then don't leak when there are alert messages?

I expect closing a connection leaks quite a bit about what came just
before the close.  I expect timing leaks quite a bit---and an adversary
who can be slightly active (e.g., opening his own connection to the
server) can learn about timing differences between alerts and ordinary
data.  I don't see how to keep content-type secret without lock-step
timing---which requires not just padding, but a habit of sending
packets with no application data, just padding, on clock ticks.  That's
extremely expensive for performance, if we make a general practice of it.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jul 2014 16:57:08 +0100

I don't have a strong opinion on the topic in the subject line but...

> think that TLS can (or should attempt to) do the job.

While traffic analysis mitigation is definitely hard and we probably
do not yet have enough expertise in that space, I do think we should
be trying to do as much as we can that might enable such mitigations
as we learn more about 'em. In other words, I think we should be
leaving extension points where we can that'd allow for traffic
analysis mitigations to be defined later (or by implementers). That
said, I'm not sure if this is useful enough in that respect or not.

Cheers,
S.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 28 Jul 2014 23:04:45 +0300

> analysis---and then don't leak when there are alert messages?

Challenge accepted

Assume that the path is deemed wide enough to carry 3 MB/s. We will limit ourselves to slightly less than that, so let’s say 2000 records of 1400B plaintext a second in each direction.

The sender (whether client or server) has two buffers, a system buffer and a data buffer. The application writes to the data buffer. If there’s an error, or the application wishes to close, an alert is placed in the system buffer.

Every half millisecond, the TLS stack performs the following:

* if the system buffer is not empty, retrieve an alert, pad to 1400 bytes, encrypt, and send.
* else if the data buffer is empty, generate a record with 1400 pad bytes, encrypt and send.
* else if the data buffer contains at least 1400 bytes, create a 1400-byte record, remove 1400 bytes from the buffer, encrypt and send.
* else create a record with all remaining data, pad to 1400 bytes, encrypt and send.

This is assuming that the attacker can’t distinguish the number of “ifs” you ran through. Otherwise, don’t send the record, but store it and send it the next time the timer expires. That also takes care of any timing side-channel you have in your encryption function.

Note that I’m not advocating doing this with TLS. IPsec has this feature and to my knowledge nobody uses it.

Yoav

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jul 2014 14:15:40 -0700

On Mon, Jul 28, 2014 at 8:14 AM, Nikos Mavrogiannopoulos
<[email-masked]> wrote:
> On the contrary, all _new_ ciphers are stream (GCM, CCM)

Now you've got me scratching my head, because both GCM and CCM are
authentication modes for block ciphers, not stream.

-- 
Colm

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 29 Jul 2014 00:23:50 +0300

> On 29.7.2014, at 0.15, Colm MacCárthaigh <[email-masked]> wrote:
> 

They are both authenticated counter modes for block ciphers, which means they behave like stream ciphers. Even though the output from the cipher comes in blocks, all redundant bytes in the end can be dropped, unlike in CBC mode. 

Therefore 2 byte alert encrypted with GCM or CCM is still 2 bytes plus the authentication tag. I believe this is what Nikos meant.

Juho

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 28 Jul 2014 14:26:38 -0700

On Mon, Jul 28, 2014 at 2:23 PM, Juho Vähä-Herttua <[email-masked]> wrote:

> They are both authenticated counter modes for block ciphers, which means
> they behave like stream ciphers. Even though the output from the cipher
> comes in blocks, all redundant bytes in the end can be dropped, unlike in
> CBC mode.
>

FWIW, TLS has this idiosyncratic defn. of the term "stream cipher" that
matches
RC4 but not AEAD ciphers or even CTR mode... Hence comments about how
we are deprecating stream ciphers but not GCM.

-Ekr

> Therefore 2 byte alert encrypted with GCM or CCM is still 2 bytes plus the
> authentication tag. I believe this is what Nikos meant.
>
>
> Juho
>

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 28 Jul 2014 15:46:18 -0700

> Of course, non-fatal alerts are (1) rare, and (2) not always treated as such, so it’s easy to spot the alert record, because it’s the one before the FIN or RST. In DTLS alerts are mostly non-fatal,…

To clarify the relationship between encrypted content types and padding:

In order to pad messages, we need to encode the amount of padding
somehow so that the receiver can strip the padding.  That means that an
unpadded message has to be distinguishable (by the peer) from a padded
message.  If we can steal a bit from the content type to indicate the
presence of a nonzero amount of padding, then we can do this with no
size overhead for unpadded messages.

For this to work, the content type must be encrypted.

--Andy