Re: [TLS] Application layer interactions and API guidance

Watson Ladd <> Sat, 15 October 2016 00:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E201129537 for <>; Fri, 14 Oct 2016 17:50:04 -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 wYPRHtFWEs3M for <>; Fri, 14 Oct 2016 17:50:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 21F301293EC for <>; Fri, 14 Oct 2016 17:50:02 -0700 (PDT)
Received: by with SMTP id f128so161699922qkb.1 for <>; Fri, 14 Oct 2016 17:50:02 -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=Y74UHMrURRzfkRiHBe+T07XBJ4Xp0A+yUi96SEkeVPU=; b=dpCderFQWzFlNbzbpWAqp1jJuNOMGTi3fRWAF58R4zKgI10nbetw+NsRi8lQZGMgt4 S0+jVafXfx5lvKlj+kpsFFMbZT0szuRk/iAxjbl1qvkgB1+/Lw76/9C9d+msTNJPyPRf daDTuw2TuqyT6TgP1qR6z0pfqya0jggC3aAQ9VW/+61fi5Hb0i5hjQseIrrJibHA+TND U6Sm2ooAzBTeDAjCASZjAEfwnzke4L3B7UavK/SsntydV2LLjw6qVEEYbp4UH183Doqh QVgE+sxTHslcLDXaohfRofHS+GNH5i5iFQNcTtOU0vDWSlZdRvDRajoEkw9V5DGg+RpP FJqw==
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=Y74UHMrURRzfkRiHBe+T07XBJ4Xp0A+yUi96SEkeVPU=; b=So9C/bNETqzZLHJ81U5hBu2S5IBZ7icf2ukWdD+eMHEtOBPG52jkCv7X1evM7AQmKN befaZsLkZ+OrPho/E0efcr69VGRocch73+mWiVaEvuYHJqwdaXUFX3GV0Kx8q59s1IFD u530u0KgTkx+AT5WD/mrTkMpER/ayUyLDzPYacxttwzaE7DqNqsknAjLAOckc9xb/RaP 9x1EujbeJ2pqVhjtCvtDn8DDuye/3DMaXZdtR3zc/y6xTNGdn1eWE/Of7GNQwrrBGDKg 7W5oxoNTHxLR0u5V++Dd9eUdf+vXG22rGp+wQ/mqHhP37BZgK+XCX2n6QWicNAghQGoJ aMhg==
X-Gm-Message-State: AA6/9Rmq3XELwAENn5adT0bw+OkRztJGBol+uXmjrpptln7CO/i8KkG+dpXTK/n6c9/2qst/QAmkxxWi4vtcLg==
X-Received: by with SMTP id k5mr13811611qkd.67.1476492601260; Fri, 14 Oct 2016 17:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 14 Oct 2016 17:50:00 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Watson Ladd <>
Date: Fri, 14 Oct 2016 17:50:00 -0700
Message-ID: <>
To: Martin Thomson <>
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: Sat, 15 Oct 2016 00:50:04 -0000

On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson
<> wrote:
> 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.

See This is for API
guidance rather than applications, and definitely needs expansion. I
don't think we can say anything about HTTP without more details.

"Man is born free, but everywhere he is in chains".