Subject: [TLS] Application layer interactions and API guidance

From: Watson Ladd <[email-masked]>
Date: Fri, 23 Sep 2016 16:08:38 -0700

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 24 Sep 2016 08:47:30 +0300

> extensions which influence the interpretation of this data must be the

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).

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.
 
> if the 0-RTT data can't be cleanly parsed, and some leaks into 1-RTT,

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.

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.

> directions, and life gets interesting. I'm really not sure what this

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.

-Ilari