IETF Logo Mail Archive

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

Watson Ladd <watsonbladd@gmail.com> Sun, 06 December 2015 02:10 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 749291B2EAF for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 18:10:15 -0800 (PST)
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 bFDvXPCSihK1 for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 18:10:14 -0800 (PST)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 0BDB31B2E99 for <tls@ietf.org>; Sat, 5 Dec 2015 18:10:14 -0800 (PST)
Received: by ykba77 with SMTP id a77so161707885ykb.2 for <tls@ietf.org>; Sat, 05 Dec 2015 18:10:13 -0800 (PST)
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=rcH8X1l+eZND90zHB8TIhOd1RO2QCubdjkVC7WgW+Io=; b=q1eLWMI92S6ejn9b6B1Y1XV2yNI8mZuJ0iVRLmb67PAnotsW2485g2bu+s7m0zlYMO qYp9xGVDGuPdvlKTAKXaJ4qgf+QxAwKjkqSalWmUJ/30n/HbCNNIobp0LTEXr2DoDZQj gCeQPU7dD/ARVpWCjo2rqlrfNg35YYfyMi++Ix98ccHissYsPDudx4PGItvzWuk375UT /O4YKDMs10d4rAR4DkcmiE73xq7w8LjFE+HKmb7WUF50CAW0sFPz3VQ1yjGOHNzCqnwE Yad5MWfvLRet8F0ZteCSvVM5PkxhvvNRWoh6StgsOTY9xcKKkgkgXaMaGlVW7kQ+BiU2 je8w==
MIME-Version: 1.0
X-Received: by 10.129.57.135 with SMTP id g129mr15960719ywa.244.1449367813252; Sat, 05 Dec 2015 18:10:13 -0800 (PST)
Received: by 10.129.148.131 with HTTP; Sat, 5 Dec 2015 18:10:13 -0800 (PST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz>
References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <CACsn0ckLkgMA2xHphro-a1N3tr+NJAvRV_NvVKP2K-=7zj1OfA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz>
Date: Sat, 05 Dec 2015 21:10:13 -0500
Message-ID: <CACsn0cmUzez7zttX+F-axEfCo098FWOWyj2UkBuV2Nc+weoSqQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/YVKCLrLgbHTVK_Uzbrawjhk_eqs>
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: Sun, 06 Dec 2015 02:10:15 -0000

On Sat, Dec 5, 2015 at 8:18 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> Watson Ladd <watsonbladd@gmail.com> writes:
>>On Sat, Dec 5, 2015 at 6:54 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
>>> Hubert Kario <hkario@redhat.com> writes:
>>>
>>>>miTLS does accept Application Data when it is send between Client Hello and
>>>>Client Key Exchange and rejects it when it is sent between Change Cipher Spec
>>>>and Finished.
>>>
>>> Given that miTLS is a formally verified implementation, would this imply that
>>> there's a problem with the verification?  "Beware of bugs in the above code; I
>>> have only proved it correct, not tried it"?
>>
>>Are you saying there is a security flaw with the behavior described?
>
> I hadn't even thought it through to that point, more that you're not supposed
> to accept anything between Client Hello and Client Keyex except an optional
> Client Certificate.
>
> (OK, I haven't gone through every extension RFC and draft to see what else you
> could poke in there, but I'm pretty sure Application Data isn't one of them).

miTLS did not claim to be consistent with the RFC. Rather it claimed
to be secure, and to interoperate with most other implementations in
circumstances tested. The informal nature of the RFC makes it
impossible to carry out formal verification against it.
>
> Peter.



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

v2.23.0 | Report a Bug | By Email