Re: [TLS] Encryption of TLS 1.3 content type

Andy Lutomirski <> Mon, 28 July 2014 22:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3FD971A02E2 for <>; Mon, 28 Jul 2014 15:46:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5XwBkfhFsgBB for <>; Mon, 28 Jul 2014 15:46:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7EE691A0092 for <>; Mon, 28 Jul 2014 15:46:21 -0700 (PDT)
Received: by with SMTP id rd3so11284406pab.14 for <>; Mon, 28 Jul 2014 15:46:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3TDNZhR6gzuLTKcGs1ZupZEu+NUtpOquW/qgBou0jhA=; b=BGXBsKr1x17kj2l+qwaYSINPabGYDXWFjtlotfqi9inaTV/phoeV5Ha7O22iRU0AK6 IZuZ0xydG1goiEAW/G2mmUrKLlosrU+UnNDGIe36Dou8Hfft89N0j/TA2UH7Mej64R6m e2tWN+RT6DTBy6w32HrjTGKX6/d+ync4kv8ICSK6OW9vi45h1FrHgj0/kYpAD7s0KIXa 5tjMTadeavot/WTNPvsfP+IfOc2xs4OF5ZT+kJLiYq2koOAhjWz9s0zqj1d9wtysajKh QNcXJaUsZpsfNCBK3PyGQnNizltZYb/K+ZZln6Yd4yEX3BiNMT9fIYozSWU9MBSMSrb2 dggQ==
X-Gm-Message-State: ALoCoQkMf8zCbShqxPJ28+QYwAl/dWUlXw7ZVw6nebau8hnSUQSLVObTJ68YE+Fw4tIGWfuJM6YL
X-Received: by with SMTP id uz11mr9219796pab.96.1406587581158; Mon, 28 Jul 2014 15:46:21 -0700 (PDT)
Received: from ( []) by with ESMTPSA id ml5sm70964638pab.10.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 15:46:19 -0700 (PDT)
Message-ID: <>
Date: Mon, 28 Jul 2014 15:46:18 -0700
From: Andy Lutomirski <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Yoav Nir <>, Nikos Mavrogiannopoulos <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: "<>" <>
Subject: Re: [TLS] Encryption of TLS 1.3 content type
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 28 Jul 2014 22:46:23 -0000

On 07/28/2014 03:52 AM, Yoav Nir wrote:
> On Jul 28, 2014, at 11:55 AM, Nikos Mavrogiannopoulos <> wrote:
>> On Sat, 2014-07-26 at 10:59 -0700, Colm MacCárthaigh wrote:
>>> On Sat, Jul 26, 2014 at 10:43 AM, Watson Ladd <>
>> wrote:
>>>> 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.
>>> 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.
>> 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.
> 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.

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.