IETF Logo Mail Archive

Re: [TLS] Separate APIs for 0-RTT

Benjamin Kaduk <bkaduk@akamai.com> Tue, 13 June 2017 18:04 UTC

Return-Path: <bkaduk@akamai.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 42F4F129457 for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:04:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 RDlec5BuA-_D for <tls@ietfa.amsl.com>; Tue, 13 Jun 2017 11:04:23 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 66E3E129464 for <tls@ietf.org>; Tue, 13 Jun 2017 11:04:23 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DI4L4O015771; Tue, 13 Jun 2017 19:04:21 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=L0U8Bk8ObzO2s7PUHx/Gn+UB0s87+Y/VaHuBnSMU5RM=; b=XUmOaIgofs345aIAnEpMXFwfmOvJcmJ4QQzxEnKenmTqq9NvQ79WIklFXh9noJqkRMwM jX+u4AOiJEc++m3u5dNM+1A5dNYAM6b9sTSn7ztoS+aeeVYQAFd79ArNJBq9/xuC+xi3 FwTrWlzguihQbmyvqNh9ZiYtgEBcbX44Mpc7DSvDRa9i2C4LjbNo5VCBUr5WVooorQfT RrcqDuxySY28tT3wv+ACy6Rmz/ourMjiHRBlKJER6NpkLN8C4pyVrsNO1RFzm9R1bamA iS9F0RTQDPL1SXFB6snQDE2V+rWkZhvwpB7tPrZhD2dZcK0eC8oKZQFuWRWENQrun9r1 4Q==
Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2b2javs9ws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 19:04:21 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DI16Ax019400; Tue, 13 Jun 2017 14:04:20 -0400
Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vqt00-1; Tue, 13 Jun 2017 14:04:20 -0400
Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id C40AA20069; Tue, 13 Jun 2017 12:04:19 -0600 (MDT)
To: Colm MacCárthaigh <colm@allcosts.net>
Cc: Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
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>
From: Benjamin Kaduk <bkaduk@akamai.com>
Message-ID: <bf4506e7-13ce-ce7f-d20e-67a0d73c642a@akamai.com>
Date: Tue, 13 Jun 2017 13:04:19 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAAF6GDfyqMndibTujY83_Xha2dZn7qvaCpZJw7xZ--b=-EOaYA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------A89820F635BCB5AE4A1C942C"
Content-Language: en-US
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130310
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130310
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/yAulzEaAmrtjUYSzsFXlrnIfirU>
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:04:25 -0000

On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote:
>
>
> On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <bkaduk@akamai.com
> <mailto:bkaduk@akamai.com>> wrote:
>
>     That's fine with me as well, though I am now considering the
>     question of having an API for the server application to know
>     whether a given request was received over 0- or 1-RTT.
>
>
>
> For s2n, I'm leaning towards recommending the opposite; signaling on
> the client side, if opt-in 0-RTT fails, but no signaling on the server
> side (though still opt-in). My reasoning is based on experience with
> that "X-" server-side header trick; it misleads people into what's
> going on in a way that leads to brokenness. The application people
> think they only have to de-dupe the 0-RTT sections, but that's not true. 
>

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.

-Ben

v2.23.0 | Report a Bug | By Email