Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Watson Ladd <watsonbladd@gmail.com> Fri, 16 October 2015 13:16 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49AF1B2AA9 for <tls@ietfa.amsl.com>; Fri, 16 Oct 2015 06:16:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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, SPF_PASS=-0.001] autolearn=ham
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 Lz868JmO7iKq for <tls@ietfa.amsl.com>; Fri, 16 Oct 2015 06:16:03 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::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 3CA5D1B2AA7 for <tls@ietf.org>; Fri, 16 Oct 2015 06:16:03 -0700 (PDT)
Received: by wicll6 with SMTP id ll6so9555387wic.0 for <tls@ietf.org>; Fri, 16 Oct 2015 06:16:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=GThZTNAIoDvVaJyLFJjVeUcAbUvTY96//k7acxYcBVA=; b=IktHqiml0jx1vqtjl6XZQxWIrq14JDMmvvfxcsBqyjxEpntsJVLOVDwPHtQMG3cxU3 ov415tnrwCNr9av92db8uEzzqY6lYRqWT94xRt3wg1jlJka629X648LBZW/xOPdwI8nQ J4+VCDBHQ2/h1SNMi8y2l7jvpYL1vt+TvuVuv7VVR9BNdXZSOzFArCLst1AitumzwuYI XELwcvXHnq7+8I/JDFYA5vMF5YK0hisrgFD5Z3KouLl67qkKJmlkwD4CVME8ZKd6S32i xKvAytEOs6yksItrPXIUpaw5shuOcUi7esHR5TbvGGT4tmJtElMkMLO3GAXMSCeG2oA+ Avag==
MIME-Version: 1.0
X-Received: by 10.180.186.10 with SMTP id fg10mr4814825wic.30.1445001361788; Fri, 16 Oct 2015 06:16:01 -0700 (PDT)
Received: by 10.28.51.145 with HTTP; Fri, 16 Oct 2015 06:16:01 -0700 (PDT)
In-Reply-To: <561FA62C.9030801@baggins.org>
References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <561FA62C.9030801@baggins.org>
Date: Fri, 16 Oct 2015 09:16:01 -0400
Message-ID: <CACsn0cn=AewVeEmuwFa_SLfYE_Y3rbuw9R4dhpu5TcX9+x_3vw@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Matt Caswell <frodo@baggins.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ITmZ_c8lyeowcjqJHDi6GMAWDbI>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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, 16 Oct 2015 13:16:05 -0000

On Thu, Oct 15, 2015 at 9:12 AM, Matt Caswell <frodo@baggins.org> wrote:
>
>
> On 15/10/15 14:00, Martin Rex wrote:
>> Is the particular interop problem that you want to address
>> caused by a necessity to really process application data and
>> handshake data with arbitrary interleave,
>>
>> or is it rather a problem of getting back into half-duplex operation,
>> i.e. a client being able to continue receiving application data
>> up to a ServerHello when it has sent out ClientHello, or a server being
>> able to continue receiving application data up to a ClientHello
>> (or warning level no-renegotiation alert) after the server has sent
>> a ClientHelloRequest?
>
> The former. The existing code should cope with the half-duplex issue. In
> the reported problem we (OpenSSL) are running as a server and we have
> received application data from the Client *after* we have sent our
> ServerHelloDone.

After thinking about this a bit this should be okay so long as you
properly present the authentication state associated with the data.
The hypothetical problem is using this to evade the protection of the
secure renegotiation extension. As a solution the new authentication
state should only be made visible to application code after receiving
a CSS/Finished. This is supposed to have exactly the same semantics as
pretending that the application data was sent before any handshake
data.

Unfortunately I don't know how to verify this. Can miTLS cover this case?
>
> Matt



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