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

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

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C461A02FE for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 09:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGu6fFekwALX for <tls@ietfa.amsl.com>; Mon, 7 Jul 2014 09:06:49 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F971A033D for <tls@ietf.org>; Mon, 7 Jul 2014 09:06:48 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s67G6h6Q021192 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 7 Jul 2014 18:06:43 +0200 (MEST)
In-Reply-To: <CABcZeBNnL8S2+OgUgg0LagWdA_aom5Qfsm0Da=ypJGhUwoepYQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 7 Jul 2014 18:06:43 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
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 (Martin Rex)
X-SAP: out
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
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Jul 2014 16:06:51 -0000

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