Re: [TLS] Application layer interactions and API guidance

Martin Thomson <> Tue, 11 October 2016 06:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E14B129456 for <>; Mon, 10 Oct 2016 23:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3bbsWGZm05VG for <>; Mon, 10 Oct 2016 23:27:25 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1A5E41293F2 for <>; Mon, 10 Oct 2016 23:27:25 -0700 (PDT)
Received: by with SMTP id z190so14675713qkc.2 for <>; Mon, 10 Oct 2016 23:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Dj7LO0+CnlLgDF12NYYP0Vd1rcp+8jFOl35TnBaF6VY=; b=Avp5jEWK6mKptp7i1FUxTfl9pkAs9VQmY0HftuBnFGFaCdpLwXymfhOwyv18VzqrQ9 CSigx2h357ejuyrgiG4gsETmrgdYhDOEMofvAiGxO0K7cO9jmTtOEFA9B0zmJrS53QZg P7IP6zlfd+IMKLVfgZy2XJwzj7eIfbTzZ5FkOPr+NrTWRUwQLX0NLg2rg1QbpFPleneP +QM7mA/jqwb9GPrVR6HRmhvbfWQJiI4kmdRYozMo8gI2Wc2+bdTbqWUpGZ5ScOIiedNn sBtqlGNJmK6PhdLH8odKjvNCQmRew3B4qJGCpMaycrYLLsuGC54xoSE/HchV+FXOcbny Kydg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Dj7LO0+CnlLgDF12NYYP0Vd1rcp+8jFOl35TnBaF6VY=; b=ZQMIu21ctc4b0dB6esucA6vGYzebyQ8tfbxFQckjFVzbWkjxOyRc2NNJyVPXh1wm8b O40Q4G6IRVbhiorYnRwcipTEJ0+GY+BA1sxWGdjQn3METnFo4/Urmart0VBgiJQeH2w3 fnjHiuJzeBKAMSLRe3RuxZPwWERkmB56pTJcZWor5Yb8iFvGTvG2E+xzWGDYXwVC1CWC Ib8AoahCSirUq3PeFd73IqC/yITfjAMcPB9Q0SJwGbc6YQTQpRMRGrOfLliA5ZCCQjTm fCfXkeC7eT15FFB6ODAeBeONB6LsqM1V9nVv+05Y7/3/E/IjPeMcO7OkBuPJx4eWZ7V4 70IQ==
X-Gm-Message-State: AA6/9RldrXOa1cbsgSUTg8gmoTkyfW44jDsqnOK6ahZBE2LBf6JJhqasZsAQG0MWPBuiOtZDWCSkEizuaEU7Bw==
X-Received: by with SMTP id d15mr1656174qke.115.1476167244144; Mon, 10 Oct 2016 23:27:24 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 10 Oct 2016 23:27:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
From: Martin Thomson <>
Date: Tue, 11 Oct 2016 17:27:23 +1100
Message-ID: <>
To: Kyle Rose <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Application layer interactions and API guidance
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Oct 2016 06:27:27 -0000

On 11 October 2016 at 07:57, Kyle Rose <> wrote:
> FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin
> that the web is substantially broken without retry logic in the browsers,
> that naturally make application-level replay mitigation a necessity. But I
> don't think (nor do I think he claimed) that the same is true of all
> protocols or systems that might use TLS. So while 0-RTT-obliviousness may be
> okay for browsers in particular given the other constraints under which they
> operate, it is probably not good to bake that into the API for the general
> case.

The 0-RTT API in NSS allows a server to detect this transition.  The
problem that I think David was referring to is that the specific
instant of the transition is lost when the multiple layers of stack
that sit on top of TLS get involved.

If an HTTP client sends a request that relies on HPACK state that was
established during 0-RTT, is it a 0-RTT request?  I'm going to go with
probably not.

If an HTTP client sends the first octets of a message in 0-RTT but
completes the request after the handshake completes, is it 0-RTT?  I
suspect that this again is not a concern.

I agree that we should make it clear that 0-RTT data needs to be
treated specially.  I would like to see someone propose some text
rather than read more vague emails on the subject.