Re: [TLS] TLS 1.3 process

"Dan Harkins" <> Mon, 31 March 2014 01:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BB0FC1A0906 for <>; Sun, 30 Mar 2014 18:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zkB0zgw0himP for <>; Sun, 30 Mar 2014 18:16:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B2F71A08FC for <>; Sun, 30 Mar 2014 18:16:22 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 2FC8FA888012; Sun, 30 Mar 2014 18:16:19 -0700 (PDT)
Received: from (SquirrelMail authenticated user by with HTTP; Sun, 30 Mar 2014 18:16:19 -0700 (PDT)
Message-ID: <>
In-Reply-To: < .nz>
References: <>
Date: Sun, 30 Mar 2014 18:16:19 -0700
From: Dan Harkins <>
To: Peter Gutmann <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
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 01:16:25 -0000

On Sun, March 30, 2014 4:46 pm, Peter Gutmann wrote:
> Dan Harkins <> writes:
>>But 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.
> Some of us are more worried about making it fit for purpose than in
> fiddling
> with crypto details.

  Well if you do not care about encryption working correctly (it's a direct
quote from the email I was replying to) then don't even bother with it;
your purpose doesn't need encryption. And bringing up a use case that
is happy with incorrect encryption is a waste of time for this WG.

>              The former requires careful thought, for the latter you
> just pull a known-good mechanism off the shelf at the end of the design
> process, plug it in, and you're done.  To quote Peter Fairbrother on the
> crypto list:
>   A similar design methodology should be used for security products (and
>   software products).  Start with the purpose of the product, then the
> human
>   and electronic interfaces, then the hardware and last of all the
> detailed
>   crypto or code. Oh yes, you think about the crypto all the way through,
> but
>   only in terms of what is possible and what resources it will take -
> worry
>   about the detailed crypto (or code) last.

  I agree. The purpose of TLS is to secure a network service (as I said
originally, see /etc/services to see who'll use TLS). If we start listing
IMAP and POP and HTTP will use TLS-- "what else?"-- it's a distraction.

>>I fail to see how documenting use cases will help us get encryption to
>> work
> It'll allow us to see whether the encryption is fit for purpose.  Since
> I'm in
> a quoting mood I'll do Bob Morris this time:
>   The behaviour of a system without a specification can never be wrong,
> only surprising.

  You should try to find quotes that relate to what you're responding to.
I never said anything about not having a specification and I never said
we need to immediately start "fiddling with crypto details". I said that
enumerating applications that use TLS is not a productive use of time
(I certainly hope you are not equating a use case document with a
specification), and I said that we are all concerned with making encryption
work correctly (in response to the arresting statement that "Watson is
concerned" about it).

> TLS has certainly shown some... surprising behaviour over its lifetime.

  How would an enumerated list of the applications that use TLS, or a
use case document for that matter, have helped any of that?


> Peter.
> _______________________________________________
> TLS mailing list