Re: [TLS] Application layer interactions and API guidance

Watson Ladd <watsonbladd@gmail.com> Sat, 15 October 2016 00:50 UTC

Return-Path: <watsonbladd@gmail.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 0E201129537 for <tls@ietfa.amsl.com>; Fri, 14 Oct 2016 17:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 wYPRHtFWEs3M for <tls@ietfa.amsl.com>; Fri, 14 Oct 2016 17:50:02 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21F301293EC for <tls@ietf.org>; Fri, 14 Oct 2016 17:50:02 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id f128so161699922qkb.1 for <tls@ietf.org>; Fri, 14 Oct 2016 17:50:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.55.136.5 with SMTP id k5mr13811611qkd.67.1476492601260; Fri, 14 Oct 2016 17:50:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.171.87 with HTTP; Fri, 14 Oct 2016 17:50:00 -0700 (PDT)
In-Reply-To: <CABkgnnV6YY_GEFKe2C+k67RcJjoPBJoWx1Crat_TMkvB8E-r_Q@mail.gmail.com>
References: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com> <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0cnpEq_00R37WZOm39dg9dXKSkpNjGt3FWg0uLgTEkwtRw@mail.gmail.com> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNU0HVqkZm6zb63xZzf4+ZQjXb8CacuYH77Fe_=dfFPhw@mail.gmail.com> <20161008142247.GB11416@LK-Perkele-V2.elisa-laajakaista.fi> <CACdeXiK1Wdnd2UaUdPJ6sL-LSW8oQbWyetUJ+3bUQEZY45ax5w@mail.gmail.com> <CAF8qwaDQqceewkg5XoN+8iiHtNO=J9YHH_aRS5+k_4fKTJvfeA@mail.gmail.com> <CACsn0ckz72rhSCQTYRvmWB6n_tdvB5E-V7ssV6qjGO6=qsXY+w@mail.gmail.com> <CAJU8_nWttdcOX=wHOqouZEpFyP3Tok0xTDCzvMrBunkSW9kO+w@mail.gmail.com> <CABkgnnV6YY_GEFKe2C+k67RcJjoPBJoWx1Crat_TMkvB8E-r_Q@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 14 Oct 2016 17:50:00 -0700
Message-ID: <CACsn0c=FO8=80F2oH_VsHknRhn8V1D4G-BaTDP4cc1cGHMYJWA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FoAmOP9r_ZbvqEogYaNFDgpQsG4>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Application layer interactions and API guidance
X-BeenThere: tls@ietf.org
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." <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: Sat, 15 Oct 2016 00:50:04 -0000

On Mon, Oct 10, 2016 at 11:27 PM, Martin Thomson
<martin.thomson@gmail.com>; wrote:
> On 11 October 2016 at 07:57, Kyle Rose <krose@krose.org>; 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 https://github.com/tlswg/tls13-spec/pull/694. 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".
--Rousseau.