Re: [TLS] Application layer interactions and API guidance

Eric Rescorla <ekr@rtfm.com> Sat, 08 October 2016 17:13 UTC

Return-Path: <ekr@rtfm.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 AE82E12954F for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:13:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 JslhM3q8zdwR for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 10:13:49 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 25A8E1293FE for <tls@ietf.org>; Sat, 8 Oct 2016 10:13:49 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id w3so21960941ywg.1 for <tls@ietf.org>; Sat, 08 Oct 2016 10:13:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nSUA/oi5lpmodzeOVvrDJ+6BEjZi7O4eRS5YnOx5EQw=; b=KSxj4/ID4ot/qdb2IH3T0vnx9HPJ8vZQTnJvxYpIdrDPANNz1pgXfFJqlem9BT/LJC IM+k2h7Hri+Mqxyk9ddno7wHSLbClE1FF0aSENxqunb8TRE+QjFhdNHQrk/vnE4Vt5Dl jKhdnNzGLiIQH9wLHraFblP8q23K1wpb2JLc/97JngGJz2DUxZRZ+FSIQyna4fgEnA64 vMA4Duf3kCxOa8Lso2/wJyzWegCPIAT8NJ9zW85W+9zxpnf2Jm4enwWpnAqO3V4wTB3u yATc9eXB0fS9WdoligoFzkqca6qwVMIW4V3D057R/xdxYFNBgPASvP41Fm+LH3g35sQS hMbA==
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=nSUA/oi5lpmodzeOVvrDJ+6BEjZi7O4eRS5YnOx5EQw=; b=AunPNHkDvz8h1PcrQUoTBZoZtlUljzavI8HiRPserh3R5Uzkv9ymSPY6qI8UhSitxS zKI8Ds9d8BDaIpC/Rpu21uzWPl3HNBmMS6jCNQtm/Gcb0GHwPwV530C5Hq3IBn69lDYV QL62VfenEiI5pOw9xOJhHWAJhQt1UiXDQfbS9q01JzVrR4ojQweon/Gda9pKdWoBLpeo DLHXbYTz9ClXF5wLGwz+lZ9ZCUB7ilVLDzvuKODAdKsTagrRFlVSpocS7/Y/wGUk9d+l 7cDD/Oa9L/1DOm/U7mwf7G0YaGbZcjr2Vquidrdkl1ICGHsJKU4zmeG0ngXFqjgjvbCx OMzw==
X-Gm-Message-State: AA6/9RntM4ABe8ZUUAdfJYhyvSlheKCtJxObW4mYGsy2V9MELvDc6sw1SKl8+LUnBsDc4AgiH6i1uWxuPMCQDg==
X-Received: by 10.129.125.198 with SMTP id y189mr19249617ywc.234.1475946828431; Sat, 08 Oct 2016 10:13:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.75.212 with HTTP; Sat, 8 Oct 2016 10:13:07 -0700 (PDT)
In-Reply-To: <20161008170605.GB12067@LK-Perkele-V2.elisa-laajakaista.fi>
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> <CACsn0cnMEVbqtG+FeP84KtmE0=5SkHqGVQ3esqZeqGf9-r6U_w@mail.gmail.com> <CABcZeBMgfqytHTptFt9bAtUktpLVRjgRPfBF52d+UYaariGiDA@mail.gmail.com> <20161008170605.GB12067@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 08 Oct 2016 10:13:07 -0700
Message-ID: <CABcZeBO-4HRvFTFjM2yvFF-=Yv45+bFUhfd8wqfcFFT0RfdoSw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="001a114926a06ab23d053e5da6e7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Oin8768qq6vG685c5osT--AL9ak>
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, 08 Oct 2016 17:13:50 -0000

On Sat, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
> >
> > In the APIs people have been designing, 0-RTT can become 1-RTT but not
> the
> > other way around.
> > Specifically:
> >
> > - There is an option to allow 0-RTT writing
> > - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT
> modes.
> > - There is a callback that tells you when you have gone from 0-RTT to
> 1-RTT.
>
> I really hope I misunderstood what you wrote...
>
> I understood it as: The TLS client library notifies the application
> that it has transitioned on its own, without instruction from client
> application from sending 0-RTT data to server to sending 1-RTT data
> to the server???
>

Approximately.

It's a little more subtle than that b/c individual SSL_Write() calls don't
cross boundaries, so at any
given time you can interrogate what state you're in, but it's really not
practical for the client
app to tell the stack what state to be in, because the stack responds to
receiving the server's
Finished by sending end_of_early_data and then its own Finished, so it's
not like you can
keep it on sending 0-RTT at that point, though of course if you had two
APIs, you could
generate an error when the client tried to use the wrong one.

Can you elaborate on your concern here?

-Ekr



>
>
> -Ilari
>