IETF Logo Mail Archive

Re: [TLS] Separate APIs for 0-RTT

Ilari Liusvaara <ilariliusvaara@welho.com> Tue, 13 June 2017 18:35 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 2F60B129488 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 GSQdqQG8rbs5 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:35:46 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B79FB127843 for <tls@ietf.org>; Tue, 13 Jun 2017 11:35:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6C29239609; Tue, 13 Jun 2017 21:35:42 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7CdX5rOBgOFq; Tue, 13 Jun 2017 21:35:41 +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-smtp3.welho.com (Postfix) with ESMTPSA id 6C4192313; Tue, 13 Jun 2017 21:35:41 +0300 (EEST)
Date: Tue, 13 Jun 2017 21:35:36 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBPkRhjLNT2QKO+DgfjE8-e-KrJ5XOLbA9bR24R1Fd96MQ@mail.gmail.com> <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAAF6GDePg9FL0JgzrWrTcrK7X=J0_fKjHVCj9EScvyQobJWTKA@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/AIfYtBnykwpmS1-9qhcONLNXBpY>
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 18:35:48 -0000

On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:
> On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> > I have been operating under the impression that at least some application
> > profiles for early data will require that certain application protocol
> > requests (e.g., something like HTTP POST) must be rejected at the
> > application layer as "not appropriate for 0-RTT data", which requires the
> > application to know if the request was received over 0-RTT data.
> >
> 
> 
> That's a really good point; you've changed my mind. It's obviously a good
> idea to return a 5XX to a POST over 0-RTT and that would need this.

I think the proper code to send is 400. The request is client error,
nor server error, so it is 4XX. And there does not seem to be suitable
4XX code, so it goes to catch-all client error code 400.

For HTTP/2, refusing the stream (sending stream error 7 without sending
server headers)  is also a good choice, as this should trigger a
retransmission of the offending request (POST requests failed by
refusing the stream are retryable).


-Ilari

v2.23.0 | Report a Bug | By Email