Re: [TLS] Encryption of TLS 1.3 content type

Yoav Nir <> Mon, 28 July 2014 10:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E82B1A020A for <>; Mon, 28 Jul 2014 03:52:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id leBGIUUA5CVF for <>; Mon, 28 Jul 2014 03:52:30 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3D2CA1A03EF for <>; Mon, 28 Jul 2014 03:52:30 -0700 (PDT)
Received: by with SMTP id x12so7265787wgg.16 for <>; Mon, 28 Jul 2014 03:52:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UfR66JqOqlowVapzyizSKnMLsDxSx2Ywp2ay3/U6o2s=; b=vGYSxKFNBRvbY9oMw+KFpcwAk6Ph2xWb+4XoVitOocsMk9ygekoWX7CpMCBWJR1BBl Dae+RgHsza+L5gLgKXuPeSPLMeyWo+iRh2JIr9RGn3u9dB2AsKafPs0frbeFPLdUHq/s jGiRh+CINVJ8W1+PnAsUUdEzWn6JIZMUpG7doc5BGHIwlYeKGmcPZlLUJuobswjzYk1Y 8OSFTgIWuj9hhiDV7x6SwopORmoxY30GQZ7aa09Woqi5xheb1miNRiPsWNzK+7fjjre/ vjCuz34hqthaH8X9uKJtG+8yTMZcXLAu0vt9bUlC4hh6yGoEp34QL+ceTeKmln1sGpOW kZVg==
X-Received: by with SMTP id e4mr30843312wij.12.1406544746739; Mon, 28 Jul 2014 03:52:26 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id u7sm2134918wif.3.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 28 Jul 2014 03:52:26 -0700 (PDT)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 28 Jul 2014 13:52:22 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Nikos Mavrogiannopoulos <>
X-Mailer: Apple Mail (2.1878.6)
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 10:52:35 -0000

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.

> 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. 

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