Re: [TLS] Application layer interactions and API guidance

Ilari Liusvaara <ilariliusvaara@welho.com> Sat, 24 September 2016 05:47 UTC

Return-Path: <ilariliusvaara@welho.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 8C1AF12C022 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 22:47:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.216
X-Spam-Level:
X-Spam-Status: No, score=-4.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.316] autolearn=ham autolearn_force=no
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 XSxjr74r4tE4 for <tls@ietfa.amsl.com>; Fri, 23 Sep 2016 22:47:42 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7B6DD12C029 for <tls@ietf.org>; Fri, 23 Sep 2016 22:47:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 95C67164CD; Sat, 24 Sep 2016 08:47:40 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id gdx3qX2rNklT; Sat, 24 Sep 2016 08:47:34 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 561DB2315; Sat, 24 Sep 2016 08:47:34 +0300 (EEST)
Date: Sat, 24 Sep 2016 08:47:30 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/63E60kgh7fzUjAAmXIao0AUqwCA>
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, 24 Sep 2016 05:47:44 -0000

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

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.


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.


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


-Ilari