Re: [TLS] TLS 1.3 process
"Dan Harkins" <dharkins@lounge.org> Sun, 30 March 2014 16:23 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 DF09A1A0895 for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 09:23:19 -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 9B-Iayf25Q3k for <tls@ietfa.amsl.com>; Sun, 30 Mar 2014 09:23:18 -0700 (PDT)
Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 31EFE1A065C for <tls@ietf.org>; Sun, 30 Mar 2014 09:23:18 -0700 (PDT)
Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D5764A888012; Sun, 30 Mar 2014 09:23:14 -0700 (PDT)
Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sun, 30 Mar 2014 09:23:15 -0700 (PDT)
Message-ID: <8812ef304b84ab08775b790b9a2ac415.squirrel@www.trepanning.net>
In-Reply-To: <r422Ps-1075i-3F3E24809EA445E4888C1202C5515245@Williams-MacBook-Pro.lo cal>
References: <r422Ps-1075i-3F3E24809EA445E4888C1202C5515245@Williams-MacBook-Pro.local>
Date: Sun, 30 Mar 2014 09:23:15 -0700
From: Dan Harkins <dharkins@lounge.org>
To: Bill Frantz <frantz@pwpconsult.com>
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/1fKtglmRTw6reTphVnbwcRtUT08
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: Sun, 30 Mar 2014 16:23:20 -0000
On Sat, March 29, 2014 8:05 pm, Bill Frantz wrote: > On 3/29/14 at 6:57 PM, dharkins@lounge.org (Dan Harkins) wrote: > >>See /etc/services. Basically, everything that uses the transport layer >>should be able to use transport layer security if it wants to. > > Transport layer doesn't have key agreement, end point > authentication, reconnect etc. etc. etc. That's what Transport Layer _Security_ (i.e. TLS) is for. > We need use cases to > define what is needed in these areas. I disagree. > 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. Well bully for Watson. 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. 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. > 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". Dan. > Cheers - Bill > > ----------------------------------------------------------------------- > Bill Frantz | Since the IBM Selectric, keyboards have gotten > 408-356-8506 | steadily worse. Now we have touchscreen keyboards. > www.pwpconsult.com | Can we make something even worse? > >
- [TLS] TLS 1.3 process Sean Turner
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Martin Thomson
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process t.petch
- Re: [TLS] TLS 1.3 process Stephen Farrell
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process Douglas Stebila
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Nikos Mavrogiannopoulos
- Re: [TLS] TLS 1.3 process Adam Langley
- Re: [TLS] TLS 1.3 process Eric Rescorla
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Trevor Perrin
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Eric Rescorla
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Salz, Rich
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Bill Frantz
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Watson Ladd
- Re: [TLS] TLS 1.3 process Dan Harkins
- Re: [TLS] TLS 1.3 process Peter Gutmann
- Re: [TLS] TLS 1.3 process Andy Lutomirski
- Re: [TLS] TLS 1.3 process henry.story@bblfish.net