Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

Yoav Nir <> Thu, 03 November 2016 17:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0AD86129446 for <>; Thu, 3 Nov 2016 10:42:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lQJxDJV1zJcE for <>; Thu, 3 Nov 2016 10:41:57 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2EA7D129A7F for <>; Thu, 3 Nov 2016 10:41:57 -0700 (PDT)
Received: by with SMTP id p190so1708422wmp.1 for <>; Thu, 03 Nov 2016 10:41:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GmqY8e2jrOtPpSppSB7X/9GjEZz/zu5MH9HKOczO8Qc=; b=m/qr4tugKGUI9d0opWzyhpHm7omSt7/6PFNNgS3njFCV9+YSnKhH2kqdvNxH1vpO1K CvsQ0p/SYvPjMaWCwnFBtxRDIP6lFBn5uRMX9FfU2uehw0LL+wKhD8YW4bq57eEUKU5I DqgCeEeB0x1OjQZhoExbRbaAT/VBfnyOa12JIyVjGbg0NKRh8dPYVyQKIkPozyueeEIp dXQEtmUiAa3oJZcTrPpe3xh0kmE4pwRIFfa0ER86oAdc7HKcxYOlcqhYUzDrowQ5CQwS u/SEmghFsx2HIbH+BZcQxvt2FINy4zUVwrz67JPTBu+eX3B+iV3AA3lZONh9rv8HvqBM cTbg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GmqY8e2jrOtPpSppSB7X/9GjEZz/zu5MH9HKOczO8Qc=; b=eQMdLexFtYXEsh+xggjvsepDoXlHiNp3jBtGZIXJbScY50+7uI5iL9WA+1oEmGpq0o m05XBE54HQ6BtaMvvfuFSoMylmw6rgsITK3qvbamYYxlTdgclVOQrxO4f710tPhxDRQ+ gZrLD2jkpbDJncT+e63AgcFwbSum2m/PDpBT8ms2FP21U+jcQqM4xYdbi9mMuSAz8fPp TG9cb8NjwKerkPSTBBl4/YjgV7885mLWV5w0SBhKdUiWmqdkJqt4eCHMBZWtbkbJF130 tDT3NtpMjRlo7GrfVlxx1maT7DG02vG9O88tlmGqnLbSNAOlsuXiIS7mMBxGsqYzzGt9 //hA==
X-Gm-Message-State: ABUngvf4VRAgEwsVW/FJ5JcgIejcGFyYviFZJNS26TgY1BHKk59OQRGXE5yArovN3djPLw==
X-Received: by with SMTP id r7mr3043082wmd.81.1478194915624; Thu, 03 Nov 2016 10:41:55 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id l19sm133115wmg.5.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 10:41:54 -0700 (PDT)
From: Yoav Nir <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9DF00D78-C2E3-400A-933E-3057E82DB1D2"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Date: Thu, 03 Nov 2016 19:41:49 +0200
In-Reply-To: <>
To: Watson Ladd <>
References: <> <> <>
X-Mailer: Apple Mail (2.3251)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-Mailman-Version: 2.1.17
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: Thu, 03 Nov 2016 17:42:00 -0000

I don’t think this makes any difference in applications written on commodity servers using regular socket APIs.

It’s a kind of architecture that has a quick special purpose processor that terminates the TCP and splits the incoming stream into records. The application records are forwarded to a quick crypto processor that decrypts the records and feeds them into the application. Other types of records are forwarded to the handshake processor usually implemented on general-purpose hardware with perhaps a cryptographic accelerator for asymmetric operations. That performs the handshake and feeds the key to the application processor.

With the change in TLS 1.3, the TCP terminator can no longer tell the records apart. That means that the crypto processor will have to take on that duty. That’s a change in architecture that could require new hardware as opposed to a firmware update for existing hardware.

I tend to believe that if this had been such a big deal we would have heard from more people, but I could be wrong. It’s clear to me that the mid-sized content providers who are likely to use such architectures are not yelling much.


> On 3 Nov 2016, at 19:30, Watson Ladd <> wrote:
> On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex < <>> wrote:
>> Ilari Liusvaara wrote:
>>>>> Hiding the types does have its benefits (and it is also used for
>>>>> zero-overhead padding scheme).
>>>> Nope, ZERO benefits.  But it totally breaks the middleware
>>>> _at_the_endpoints_!
>>> Also, things like this should have been discussed like year or two
>>> ago. Right now it is too late for major changes like this without good
>>> cryptographic justifications (which AFAICT don't exist).
>> They WERE brought up back then, and several times in between.
>> But the TLSv1.3 proposal has still not been fixed so far.
>> Ignorance does not make problems go away.  Instead, it means that
>> one will have to fix it later.
>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
>> which has existed through SSLv3->TLSv1.2 would be a problem.  With the
>> removal of renegotiation from TLSv1.3, it is even less of a problem to
>> keep the contenttype in the clear.
>> The removal of visibility of ContentType in TLSv1.3 will be a complete
>> non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain
>> software architectures (including a lot of stuff we've been shipping for the
>> last 5 years), because it is actively being used to signal state of
>> the communication channel to the application and to *NOT* break application
>> architecture that relies on (new) application data remaining visible on
>> network sockets as "network readable" events.
> This I do not understand. I may make some technical errors in below,
> and would appreciate correction.
> I assume we have an application that is using poll() or select() or
> somesuch for nonblocking IO (maybe something fancier, but that is
> okay).
> This application grabs data from a ready connection, rams it through
> the TLS implementation, and then looks at what comes out. But reading
> from the connection clears the data available state! However, it's
> never the case that there is visible data absent a network read or
> write after the handshake.
> So what is the content type doing here? Does the application not call
> a TLS implementation provided state function to determine what state
> the connection is in? And if so why does the record layer need to
> know, as opposed to the handshake one? I'm not seeing why the above
> style implementation is impossible: Microsoft doesn't seem to think so
> and hasn't complained about this change.
> Sincerely,
> Watson Ladd
> _______________________________________________
> TLS mailing list
> <>
> <>