IETF Logo Mail Archive

Re: [TLS] Separate APIs for 0-RTT

Petr Špaček <petr.spacek@nic.cz> Wed, 14 June 2017 06:17 UTC

Return-Path: <petr.spacek@nic.cz>
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 6D687129B33 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 23:17:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 u_ZE7lfS4Nop for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 23:17:32 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E82F129B31 for <tls@ietf.org>; Tue, 13 Jun 2017 23:17:32 -0700 (PDT)
Received: from [192.168.3.123] (unknown [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 551F06017F for <tls@ietf.org>; Wed, 14 Jun 2017 08:17:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1497421050; bh=wPFAyMSJDNTLYtTihUQMvdCuvo0m9FT7XIUpcAZd91A=; h=To:From:Date; b=r2s4NZbaSn/p1YFQZfIwRuasl3d3TzZWCk5Y/eA7hWnpJeDgbHDXIZeGyS/6ptTo0 B5RAuOnLhuV7FgNEBGbqegG4FqINegtosY4x4qQORn7KgdJPuvSuOzn/UJgxy6lpYy 3a8DVcT9w+7hROSoh8wOS60M/UiO/5GN6xmUnzu8=
To: tls@ietf.org
References: <CABcZeBMpeBhcKoJYuMwLyER0VBh+RtVr6amWMPos3CJipXYHcA@mail.gmail.com> <DM2PR21MB00916718A71749E5D2CB19C38CC20@DM2PR21MB0091.namprd21.prod.outlook.com> <CABcZeBO+Qprg4DTwNJrFU1PXDPyKbbdakMrF9fhe02jRL50cow@mail.gmail.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <CAAF6GDfyqMndibTujY83_Xha2dZn7qvaCpZJw7xZ--b=-EOaYA@mail.gmail.com> <bf4506e7-13ce-ce7f-d20e-67a0d73c642a@akamai.com> <CAAF6GDePg9FL0JgzrWrTcrK7X=J0_fKjHVCj9EScvyQobJWTKA@mail.gmail.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <DM2PR21MB0091B8DC8780B4FA67464F0A8CC20@DM2PR21MB0091.namprd21.prod.outlook.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi>
From: Petr Špaček <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <e5ab9945-054b-67bf-beef-9fce7a4a6f36@nic.cz>
Date: Wed, 14 Jun 2017 08:17:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0
MIME-Version: 1.0
In-Reply-To: <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/idqgKk0RAeorl0q_5PjLW_ylTCg>
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: Wed, 14 Jun 2017 06:17:34 -0000


On 13.6.2017 22:55, Ilari Liusvaara wrote:
> On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote:
>> Regarding RFC language, I think we could be more specific:
>>
>>
>>
>> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in;
>>
>> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in;
>>
>> 3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data.
> 
> First of these has to be MUST, or you get problems like I outlined
> earlier.
> 
> And to implement checking for client only sending "safe" data, you need
> the second and third.

I support MUST for the three points above.

-- 
Petr Špaček  @  CZ.NIC

v2.23.0 | Report a Bug | By Email