Re: [TLS] TLS 1.3 process

Bill Frantz <> Mon, 31 March 2014 00:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CA5E41A08FE for <>; Sun, 30 Mar 2014 17:34:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XIKVsBJFeRYK for <>; Sun, 30 Mar 2014 17:34:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF0BC1A08F9 for <>; Sun, 30 Mar 2014 17:34:07 -0700 (PDT)
Received: from [] (helo=Williams-MacBook-Pro.local) by with esmtpa (Exim 4.67) (envelope-from <>) id 1WUQAt-0001jH-76; Sun, 30 Mar 2014 19:34:03 -0500
Date: Sun, 30 Mar 2014 17:33:28 -0700
From: Bill Frantz <>
To: Dan Harkins <>
X-Priority: 3
In-Reply-To: <>
Message-ID: <r422Ps-1075i-A3471DDF8577467F83C8DA1615C66239@Williams-MacBook-Pro.local>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.3.1 (422)
X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c4c62d7bd057c04cfa5a4cce3f76c442350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Subject: Re: [TLS] TLS 1.3 process
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, 31 Mar 2014 00:34:10 -0000

On 3/30/14 at 9:23 AM, (Dan Harkins) wrote:

>>Watson is correctly concerned that we get the transport
>>encryption to work correctly. Transport layer encryption might
>>include bi-directional data transport, end point synchronization
>>etc., but if there are no use cases, it is hard to justify
>>spending a lot of effort to support them.
>... everyone in the WG is concerned
>about getting encryption to work correctly. We're also all
>concerned about getting authentication to work correctly.
>And about getting authenticated encryption to work correctly.
>I fail to see how documenting use cases will help us get
>encryption to work correctly, unless you think there are some
>use cases for which correctly working encryption is not a
>requirement. If that's the case then then have no impact on
>TLS 1.3.

SSL/TLS was built with one use case in mind -- HTTP. As a 
result, TLS authentication is optimized for the stranger meets 
stranger case where a user wants a secure connection to a web 
site knowing only the domain name. This HTTP oriented 
authentication is poorly adapted to the requirements of 
encrypted communication with email servers where connections 
between the email user and the server are repeated many times a 
day, day after day. What other application areas are also poorly 
served? Without use cases we have no idea.

The problem isn't that we all don't want encryption, 
authentication, traffic analysis resistance etc. to work 
correctly. The problem is that we don't know what correct 
operation is. And we can't know unless we have an idea of what 
at least some of the uses are.

>>We need use cases if only to be sure we are supporting what
>>needs to be supported.
>Documenting use cases is an unnecessary distraction from
>doing actual work. You'll note that our charter does not say
>"enumerate applications that want to use TLS".

We don't have to enumerate all the uses. What we have to do is 
have enough examples of different uses to let us have a chance 
that we are actually serving a wide range of them.

Cheers - Bill

Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032