Re: [TLS] Application layer interactions and API guidance

Watson Ladd <> Fri, 07 October 2016 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A38C0129436 for <>; Fri, 7 Oct 2016 13:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLJj0IFa-vhI for <>; Fri, 7 Oct 2016 13:41:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 92A3812940F for <>; Fri, 7 Oct 2016 13:41:15 -0700 (PDT)
Received: by with SMTP id u68so54090799uau.2 for <>; Fri, 07 Oct 2016 13:41:15 -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=0n/HjdBOQqdje+XGm2c48iHGpT6q8e1AbiD8WiXK6hc=; b=iFHV7jHztGU7DLfUFPbnJFlCPSg9PTHcMPjb/gIXHNE+HFTk83j03x8KRtce+m5xM0 SeyaocGdcl7ULMDilmsHlsKAZcLNYdYq6lnXHEhmbQjLnJMOVdlX3w1m3gU9OOP9XJsE CxBE/N9QxumDnxK+gTdLQVn95fYU7TgFMLYBKdVIg648H9cQyghdN7tbSTLW2zxbaUfy qjOJHTg90KHDb82RG9SDOqhyjM0mDmrqEDPiXfw0B8DWkR5DoXO2woCLPVysWc09CKII iwdDXqQxT4IFJ4mE8vNvSLrkOsOA+5kVTO3x+6WgLPT70uIf77qrOfm10l7vTjT/nVlJ CWtw==
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=0n/HjdBOQqdje+XGm2c48iHGpT6q8e1AbiD8WiXK6hc=; b=dd163n9ZRkncQ7Og/WqqL7TxYF3Of6i/lCTKyht+XFGxzLLcsKsYKIJhk7TE9effan JWbwgqYGlIHe5wHqniGvYR4fZtctyweNDA//czaeFAc1FY3NUgWCgITE8nuZ1kUBRnbF B/0Se2tma8V2r4KLV/hzyKQgcmjymNM/tVhs9VrU8nQS0uvW45NvOoC5kcPreYeXNtPD HJwDY++I9HvR8/IJUQjcH4A9AD82mJgz0B4loIGdEiKVyQJjmh347WlN9zKDhyvgIlW9 Y72zladv1+IcvAr7u/EB10HzplfxvhYF6GlNRaK/zN/J82RBt6/WkA8QJA4OB351Dtnr K6FQ==
X-Gm-Message-State: AA6/9RlLeXM7vEW8Xob4OoTxQ5TND6w1eiqFiSzkzMrTdeljDrgNY1YEsxr2mSwqqjRNUTnEyupwx+Jhp9aZVg==
X-Received: by with SMTP id v30mr15843524uav.28.1475872874517; Fri, 07 Oct 2016 13:41:14 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 7 Oct 2016 13:41:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Watson Ladd <>
Date: Fri, 7 Oct 2016 13:41:14 -0700
Message-ID: <>
To: Ilari Liusvaara <>
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: Fri, 07 Oct 2016 20:41:18 -0000

On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
<> wrote:
> On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote:
>> 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".
> In composing my list of extensions to pay attention when doing 0-RTT
> (SNI and ALPN), I considered matters like:
> - Does this seem like it would affect 0-RTT interpretation.
> - What are the TLS 1.2 rules on it?
> - Is it even meaningful with PSK?
> - Is it just low-level connection control?
> ALPN was included because it definitely affects 0-RTT interpretation
> (even against TLS 1.2 rules) and SNI because of TLS 1.2 rules (SNI
> was later removed from the list).

Are we sure this is safe to remove? It probably depends on higher
layer protocol semantics.

I would suggest that we make 0-RTT per application layer support: each
application needs to opt in to 0-RTT, and we should ensure each higher
level protocol is aware of the interactions and writes a description
of what to do for each extension. Yes, this is hideous and a ton of
work. I'm not convinced there is a safe alternative.

> There might be future extensions that do have an effect on 0-RTT
> (some proposed extensions to Token Binding perhaps?). And it is of
> course theoretically possible that TLS stack implements some extension
> in a very odd way.
>> 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.
> Is "life gets a bit weird" an euphemism for "there will likely be
> security issues here"? :-)
> Also, it is very likely that 0-RTT would need its own read API, because
> it is pretty unlikely that existing API could be safely retrofitted
> or even purpose-built unified API be designed that isn't just asking
> for security problems via mixing 0-RTT and 1-RTT data.

Yes. In particular I think the TLS state machine transitions need to
be ordered with respect to the arrival and sending of data. The
challenge for a multithreaded program (yes, some programs have
multiple threads sending and receiving at once) is making this make
sense, or even a single-threaded program where the TLS stack can
change state at times not visible to the sending thread. Maybe there
is some slop here, like 0-RTT can become 1-RTT on send, but this
raises all sorts of problems for receiving. I think we need to require
separation in the API.

> It gets even more fun in DTLS, where 0-RTT packets can be reordered
> after Client Finished, so more 0-RTT data arrives when the connection
> has already transitioned to 1-RTT.
> Perhaps the last one could be solved by requiring the library to
> discard any such packets and not pass them forward.

This is the sanest solution I can think of. When DTLS 1.3 is produced
it should be noted.

>> 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.
> At least you must have client and server agree on authentication
> context of every given request. If they don't, vulernabilities WILL
> result.
> And then there have been multiple CVEs due to applications using
> wrong authentication context in some situation.
> (This is the reason one needs to be especially careful when combining
> dynamic client certificates with HTTP/2... Basically, it can not be
> done safely without coordination on application layer).
> One likely wants application protocol to be able to specify part of
> or the entiere request context and to extract that part in the other
> end when requesting a certificate selection. This is to allow putting
> part of coordination data into the request itself. However, this is not
> sufficient for e.g. HTTP/2 signaling, so more needs to be exchanged at
> application layer.
> E.g. HTTP/2 would want to signal which stream triggered the client
> certificate request, in order to enable the client to not be completely
> dumb in certificate selection.
> And then upon completion of the authentication (either successful or
> explicitly rejected), signal the application with the new certificate
> chain and the context the request had.

This is going to require major changes to APIs and to the HTTP/2
layer. It also interacts with token binding, whee! My question then
becomes one of what we actually need: can we assume that leakage
between authentication contexts over a single session is safe because
all contexts represent the same principal, by restricting the usages,
or is this overly restrictive?

When we have multiple requests and replies in flight and the
authentication state changes, things get nasty. If we think of TLS as
sending a stream of events including authentication changes to the
application, this fits the semantics of the TLS draft as I understand
them to be, but does not necessarily fit what application protocols
want. There might be a semantic mismatch here requiring reworking of
one or another part.


> -Ilari

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