[TLS] Application layer interactions and API guidance
Watson Ladd <watsonbladd@gmail.com> Fri, 23 September 2016 23:08 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 2AEAF12B5CB for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 16:08:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 eLb4Jxn7nHYc for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 16:08:39 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 9320C12B4DD for <tls@ietf.org>; Fri, 23 Sep 2016 16:08:39 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 15so59895105uai.3 for <tls@ietf.org>; Fri, 23 Sep 2016 16:08:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=Di/dJ/RuDG2Lrxg+mLlCE3Z4/OLP0RJK4lQLZe2Z1xQ=; b=QM3MuW+t74gSpxDa+Hn8Gh3Cb5X5yTIxqBNBcVDdgzF7m2/TsiDEAcyBD9C8eLIYLs MLHTkRDF8vcSzIbVWDc9WHvo7UzMUvFYga2w9c954mH56ox9I7VWBt5zw745MphOwVl1 RVCaJ1m4oJMCHvE2tYB7i5Scw4BL/2C0O8fuU3Q+gmXKKtftF/Uw5yPtdpGQLp8doOva jSZf0GGdGpTCvR90pR8vXLiYz4GxjlbRBMRsSgQWyqQ34kkWhnshPcnDC0vWs1FFLkQo KBwSrp4tFRU3fUDS6+FPAGnpt1QJQIryAq22d3pKCti982IXMfTIIbyTC7Fwso1WJwI8 pY0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Di/dJ/RuDG2Lrxg+mLlCE3Z4/OLP0RJK4lQLZe2Z1xQ=; b=ThW2M//FsZLY5Bl2ghPbubSetHX/vL0p05rQ0ULGUsy3odYwXOHZI2neADbE25CmVF RRH05oW5dkB1ukflamb4+1xA+ElLkvnjoPredkDlCp6eh7k7mxxRJ1/P6glnUU1EQ/a0 ZafrX14FHOzxl7z0ybZwEg6AcnaJRk5XMeWEs9QOtUqVLqeZF6bchc8N4XIEHKI58czK 18bOHmIULgkhBSGG7DqV54vBU9QzQVKgySHvjn69aLpaDqTkPGsuvc4CWt3SpHlSHYNh UrWDcQ/pBDgb7NDJV60cyizBpxEaqio/yvxQZK8FbbErgBY1mMnwrynoPq/CzTafOJ00 LmeA==
X-Gm-Message-State: AE9vXwNrV3rGtOBpFyCRKirr0RrsIHELYRm7y+Y8qxZMxgtp4VR4xQs5GMFBLy0wBs9JCNmwyVhoN4pXl2cCKg==
X-Received: by 10.176.6.106 with SMTP id f97mr6458188uaf.66.1474672118580; Fri, 23 Sep 2016 16:08:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.4.102 with HTTP; Fri, 23 Sep 2016 16:08:38 -0700 (PDT)
From: Watson Ladd <watsonbladd@gmail.com>
Date: Fri, 23 Sep 2016 16:08:38 -0700
Message-ID: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/NqgR2NalI-c0d-aWbohcAN_F-CQ>
Subject: [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: Fri, 23 Sep 2016 23:08:41 -0000
Dear all, We've got API guidance and application layer interactions on the TODO list, and both of these are important and don't show up yet. I can't credibly commit to taking a big stab at them, but hopefully this email is detailed enough that it serves as a starting point. The problems with the application layer interaction center around 0-RTT and client post-authentication. 0-RTT data is replayable, and furthermore does not authenticate SNI or other extensions that might affect its interpretation at the server. I smell possible bugs where extension data isn't properly treated with 0-RTT vs. 1-RTT fallback: the current draft probably should include something like "any extensions which influence the interpretation of this data must be the same". The difference between received 0-RTT data and other data doesn't necessarily line up with connection state while processing, as the TLS stack could have transitioned to normal 1-RTT operation while 0-RTT data is still sitting around waiting to be processed. This is really an API problem, but can also be caused by application layer choices: if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT, life gets a bit weird. API guidance is generally pretty easy, even if most implementations have massively failed at being reasonable. I do not want to point fingers, but someone thought having true and false values mean exactly opposite things was a good idea in a C API at one point. Post-handshake auth is an ugly one for both. It can complete asynchronously with respect to data exchange, which is not what the desired semantics usually are. Generally we want each request to have a single authentication context. Designing APIs to handle this is hard, and applications will have to be aware of how TLS authentication works to have rules for it. Add in the ability to stream data in both directions, and life gets interesting. I'm really not sure what this should look like. Sincerely, Watson
- [TLS] Application layer interactions and API guid… Watson Ladd
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Nick Harper
- Re: [TLS] Application layer interactions and API … David Benjamin
- Re: [TLS] Application layer interactions and API … Watson Ladd
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Martin Thomson
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Ilari Liusvaara
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Eric Rescorla
- Re: [TLS] Application layer interactions and API … Kyle Rose
- Re: [TLS] Application layer interactions and API … Watson Ladd