Re: [TLS] Separate APIs for 0-RTT
Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 13 June 2017 10:58 UTC
Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A061316EC for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 03:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 WJsemCrgPy4i for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 03:58:51 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 93193131790 for <tls@ietf.org>; Tue, 13 Jun 2017 03:54:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 84DF929CF2; Tue, 13 Jun 2017 13:54:14 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id T8CxS3FYXj06; Tue, 13 Jun 2017 13:54:14 +0300 (EEST)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3C45721C; Tue, 13 Jun 2017 13:54:14 +0300 (EEST)
Date: Tue, 13 Jun 2017 13:54:09 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170613105409.GB8983@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBPkRhjLNT2QKO+DgfjE8-e-KrJ5XOLbA9bR24R1Fd96MQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBPkRhjLNT2QKO+DgfjE8-e-KrJ5XOLbA9bR24R1Fd96MQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/M68U_Q2JyZMJSDs7wlz4qseR1Ac>
Subject: Re: [TLS] Separate APIs for 0-RTT
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 13 Jun 2017 10:58:55 -0000
On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > The current text says: > > 0-RTT data has very different security properties from data > transmitted after a completed handshake: it can be replayed. > Implementations SHOULD provide different functions for reading and > writing 0-RTT data and data transmitted after the handshake, and > SHOULD NOT automatically resend 0-RTT data if it is rejected by the > server. > > I think the second piece of guidance (about automatic re-send) is still > good but it seems like implementations are mostly converging on a single > API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have > a single API and OpenSSL's use of two APIs is an outlier. I don't think > it's helpful to have a SHOULD that a lot of people violate, especially when > this also indicates we don't have consensus on this SHOULD. > > I propose we remove this recommendation in favor of one which simply says > that implementations should need applications to opt-in to 0-RTT. That > would allow implementations to have either API. I think it is VERY bad idea for TLS client library to do 0-RTT without application explicitly opting in to that (e.g., via setting a special setting, or using API call sequences that didn't work at all for n-RTT). Consider for example that: - The application starts by sending a POST request. - The application starts by sending a GET to confidential URL. Both cases lead to things possibly going very badly wrong if TLS library silently does 0-RTT. And both are kind of requests that might be written before TLS connection is fuly up. And if ALPN is included, there is always a possibility that the initial guess on protocol was wrong, and the data can't just be autoretransmitted, but TLS stack has to ask the application to roll back the state. The server side does not have as obvious failure modes if 0-RTT is enabled without application knowledge, but that does not mean such failure modes are not out there. -Ilari
- [TLS] Separate APIs for 0-RTT Eric Rescorla
- Re: [TLS] Separate APIs for 0-RTT Ilari Liusvaara
- Re: [TLS] Separate APIs for 0-RTT Eric Rescorla
- Re: [TLS] Separate APIs for 0-RTT Salz, Rich
- Re: [TLS] Separate APIs for 0-RTT Eric Rescorla
- Re: [TLS] Separate APIs for 0-RTT Steven Valdez
- Re: [TLS] Separate APIs for 0-RTT Andrei Popov
- Re: [TLS] Separate APIs for 0-RTT Eric Rescorla
- Re: [TLS] Separate APIs for 0-RTT Loganaden Velvindron
- Re: [TLS] Separate APIs for 0-RTT Benjamin Beurdouche
- Re: [TLS] Separate APIs for 0-RTT Andrei Popov
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Ilari Liusvaara
- Re: [TLS] Separate APIs for 0-RTT Colm MacCárthaigh
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Colm MacCárthaigh
- Re: [TLS] Separate APIs for 0-RTT Ilari Liusvaara
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Andrei Popov
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Ilari Liusvaara
- Re: [TLS] Separate APIs for 0-RTT Petr Špaček
- Re: [TLS] Separate APIs for 0-RTT David Benjamin
- Re: [TLS] Separate APIs for 0-RTT Andrei Popov
- Re: [TLS] Separate APIs for 0-RTT Brian Sniffen
- Re: [TLS] Separate APIs for 0-RTT David Benjamin
- Re: [TLS] Separate APIs for 0-RTT Colm MacCárthaigh
- Re: [TLS] Separate APIs for 0-RTT David Benjamin
- Re: [TLS] Separate APIs for 0-RTT David Benjamin
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Martin Thomson
- Re: [TLS] Separate APIs for 0-RTT Timothy Jackson
- Re: [TLS] Separate APIs for 0-RTT Benjamin Kaduk
- Re: [TLS] Separate APIs for 0-RTT Yoav Nir