Re: [TLS] proposal to encrypt ContentType for TLS 1.3

mrex@sap.com (Martin Rex) Mon, 07 July 2014 16:06 UTC

In-Reply-To: <CABcZeBNnL8S2+OgUgg0LagWdA_aom5Qfsm0Da=ypJGhUwoepYQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 07 Jul 2014 18:06:43 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140707160643.98F421AD93@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5cWfoXoJXcIJDKJBz3MoHVEEfgg
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] proposal to encrypt ContentType for TLS 1.3
Precedence: list
Reply-To: mrex@sap.com

Eric Rescorla wrote:
[ Charset UTF-8 unsupported, converting... ]
> Daniel Kahn Gillmor <dkg@fifthhorseman.net> > wrote:
>>
>> i just opened a pull request to propose that the TLS ContentType (when
>> actually using a proper cipher) should itself be encrypted, rather than
>> in the clear:
>>
>> If this change is made, it's also relatively easy to just drop the TLS
>> version field for each encrypted TLS record layer fragment.

This version field is sometimes helpful for debugging, and
using the same formatting of the record contents (clear vs. decrypted)
means less code complexity.

> 
> This seems like an idea with a fair bit of merit, but if I understand
> correctly, it's going to result in a stream of data which cannot be
> parsed into TLS records by existing network elements.
> I'm concerned about how this is going to interact with various
> elements which process the ciphertext.

There are also going to be problems with implementations where the
records are read from network in their entirety before being passed to
and processed by the TLS implementation, and where that network i/o
state machine is currently using the record type to indicate to
higher layers whether the handshake is still ongoing.  It's also
helpful to see in wireshark traces whether a connection was
terminated by a TLS alert, or whether it may have been interrupted
by some middlebox or other networking problem.

What would be the purpose/benefit of this in case that renegotiation
gets dropped?

Such a change at the record layer would reliably preculde that we
ever ship TLSv1.3, because a 2 years ago I've switched to doing
all network i/o outside of the TLS stack and parsing the records above TLS
so that we can arbitrarily mix non-blocking I/O with precise application-
defined network timeouts.

-Martin

[TLS] proposal to encrypt ContentType for TLS 1.3 Daniel Kahn Gillmor
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
Re: [TLS] proposal to encrypt ContentType for TLS… Eric Rescorla
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
Re: [TLS] proposal to encrypt ContentType for TLS… Colm MacCárthaigh
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
Re: [TLS] proposal to encrypt ContentType for TLS… Geoffrey Keating
Re: [TLS] proposal to encrypt ContentType for TLS… Fabrice Gautier
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
Re: [TLS] proposal to encrypt ContentType for TLS… Fabrice Gautier
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Thomson
Re: [TLS] proposal to encrypt ContentType for TLS… Daniel Kahn Gillmor
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
Re: [TLS] proposal to encrypt ContentType for TLS… Daniel Kahn Gillmor
Re: [TLS] proposal to encrypt ContentType for TLS… Martin Rex
Re: [TLS] proposal to encrypt ContentType for TLS… Watson Ladd
Re: [TLS] proposal to encrypt ContentType for TLS… Colm MacCárthaigh