[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 with SMTP id f97mr6458188uaf.66.1474672118580; Fri, 23 Sep 2016 16:08:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 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

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.