Re: [TLS] TLS 1.3 process

"Dan Harkins" <dharkins@lounge.org> Mon, 31 March 2014 01:16 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0FC1A0906 for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 18:16:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.867
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkB0zgw0himP for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 18:16:22 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2F71A08FC for <tls@ietf.org>; Sun, 30 Mar 2014 18:16:22 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 2FC8FA888012; Sun, 30 Mar 2014 18:16:19 -0700 (PDT)
Received: from 199.127.104.10 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 30 Mar 2014 18:16:19 -0700 (PDT)
Message-ID: <4902faea2d2548bb796379ea22330437.squirrel@www.trepanning.net>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac .nz>
References: <9A043F3CF02CD34C8E74AC1594475C738A33738A@uxcn10-tdc06.UoA.auckland.ac.nz>
Date: Sun, 30 Mar 2014 18:16:19 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
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
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/T6hoNJtMlAG-Go9iHRTxFe2Z27Q
Cc: tls@ietf.org
Subject: Re: [TLS] TLS 1.3 process
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=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 <dharkins@lounge.org> 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
that
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
>>correctly
>
> 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?

  Dan.

> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>