Re: [TLS] Application layer interactions and API guidance

Watson Ladd <watsonbladd@gmail.com> Sat, 08 October 2016 14:25 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 779D01295D2 for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 07:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 CtpC1yG58NxV for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 07:25:49 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 5D76E1295CF for <tls@ietf.org>; Sat, 8 Oct 2016 07:25:49 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id q7so32442355qtq.1 for <tls@ietf.org>; Sat, 08 Oct 2016 07:25:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LxWEZ26/k64QZkxW7por/qOflZwg6eAbhSZRVhI4qxg=; b=jn9qhHRhEzXtwbc/vGgZzAw3XEnOoQODnG3xG6lS3pze2rispRe9R9MmApRUr8ju2u f4RevbFUcsRcKSRL6/2lztlH+JXzw0wqhb09aH8LtGPB40L325tMiscbOreH8H+d8Ip6 3t/l1+RyN+fMpAjSIbJPcrYnytKL+zrz7PV5DbTumquQ5DQGKJCg7k1l5AiKJGhgPPKa LMg7JtQjqac8LH+hJnoyzcqjM597C2H/fs6dS6gK5cIeXbO4EeiD5SiBWIbZpqmYbwEt EUSyNuGsLErr3qOa0FYn+bTgU/P9q6vTcP5XVWNtUn7KnVrlUwxBTH4od9gVpirYC0Ak dEkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LxWEZ26/k64QZkxW7por/qOflZwg6eAbhSZRVhI4qxg=; b=hXrNThQ4L6Dh5i+zeXsX7W23x6T091aNbuQD0/PcMImezKnefIE8saQZPweDS/0l5M /jA6FpqjPFeht6LgN28zIneEuR2VzBhHD0waJSybpD8oR5yOQVCpESMeUhjaKNVeCrGL rqsSBDOiyh0S56Uwt1iia1TxLErteEeF9w9duXZxC6L4EDeF9JvxCtJEXlRqFCY/dkDe QcnRoBUw13RKbvf6mKRABBmjZcaIR3cUITnS2cMuyoPU7Uaec8HjM8VwX42ylIndpYAm r64znu4GBh8MNKjxnVEr3y03kEHZg5acYHWnHPUDx5vio5pkfWjHe5HDWlN1wHxyLBaz P92w==
X-Gm-Message-State: AA6/9RlR6DpiPJ/rjYi4eUqgVxfIEIhg2p1rCoYJ7vOXfFb8lBOPW8KDW+cqWCPfQs49KsjgEpbUmVcLf8YX5A==
X-Received: by 10.237.44.193 with SMTP id g59mr7848436qtd.144.1475936748360; Sat, 08 Oct 2016 07:25:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.171.87 with HTTP; Sat, 8 Oct 2016 07:25:47 -0700 (PDT)
Received: by 10.12.171.87 with HTTP; Sat, 8 Oct 2016 07:25:47 -0700 (PDT)
In-Reply-To: <CABcZeBNU0HVqkZm6zb63xZzf4+ZQjXb8CacuYH77Fe_=dfFPhw@mail.gmail.com>
References: <CACsn0c=B0dVGaXKawW5DJCUfJfqFFHkk_cZCzjzKs53n4UKLpg@mail.gmail.com> <20160924054730.GB7594@LK-Perkele-V2.elisa-laajakaista.fi> <CACsn0cnpEq_00R37WZOm39dg9dXKSkpNjGt3FWg0uLgTEkwtRw@mail.gmail.com> <20161007220028.GA10288@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNU0HVqkZm6zb63xZzf4+ZQjXb8CacuYH77Fe_=dfFPhw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
Date: Sat, 8 Oct 2016 07:25:47 -0700
Message-ID: <CACsn0cnMEVbqtG+FeP84KtmE0=5SkHqGVQ3esqZeqGf9-r6U_w@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: multipart/alternative; boundary=94eb2c12569298dae0053e5b4d54
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FShGd95gJgg83SHpw3RuWClH5is>
Cc: 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, 08 Oct 2016 14:25:52 -0000

On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com>; wrote:
>
>
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusvaara@welho.com>;
> wrote:
>>
>> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>> > <ilariliusvaara@welho.com>; wrote:
>> > >
>> > > 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.
>>
>> 0-RTT can't be allowed to become 1-RTT on send (unless it is auto-
>> retransmit, which needs to be disableable, as sometimes that just plain
>> won't work).
>
>
> Can you explain why that is?

Grammar problems.

Let's say you have an context-free parseable protocol, and you want to
insert the restriction that there is a 0-RTT set of allowed constructions
and an 1-RTT allowed set that is bigger. The most obvious way to do this is
to treat the transition as a token that comes between the top-level
productions of each set of allowable things: so I send you a bunch of 0-RTT
allowed bits, then switch, then a bunch of 1-RTT allowed bits.

If the sending stack can insert that transition anywhere the grammar
explodes.

One could try to handle this by some nasty "did we switch before now"
construction to delay the transition. But you still need to switch how you
are reading.

>
> -Ekr
>
>
>
>> This impiles that the application always needs to explicitly signal
>> the end of 0-RTT data, even just to abort sending it.
>>
>> > > (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.
>> > >
>> > > 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?
>>
>> Yes, it is going to reuqire such changes.
>>
>> And you absolutely can not assume that all contexts present the same
>> principal.
>>
>> And as I said, in multiplexed protocol like HTTP/2, you need application-
>> level coordination on top. TLS just can't do that.
>>
>> > 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.
>>
>> Also, some applications presumably want the events done synchronously,
>> so they don't move with data reads.
>>
>>
>> Basically, post-handshake auth is heckuva nasty problem.
>>
>>
>> -Ilari
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>

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