Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

David Benjamin <davidben@chromium.org> Tue, 14 February 2017 15:45 UTC

Return-Path: <davidben@google.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 AE857129627 for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 07:45:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 jvyMe_RHyI2h for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 3D9F8129483 for <tls@ietf.org>; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
Received: by mail-qt0-x232.google.com with SMTP id w20so113558957qtb.1 for <tls@ietf.org>; Tue, 14 Feb 2017 07:45:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hv/1XCKpPuo00J8YRKtHZI1/BkbmsQsaYR8LEmLAc6I=; b=SddTWzGIuJSrb+SWB+swiADJDpu/B6douu1VQIZF3Zgr8H3HczewVz1hW+zvxbwxyd G75xrwOAwJQuNkzUcdnzcL56rgqJWIoocyWtRMgCWOUEy+F4WO01gDmRPK/9277ERq7i p6Ig+Sece+qKlXsxTaohFuT9X2Cky3mpMgL/M=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hv/1XCKpPuo00J8YRKtHZI1/BkbmsQsaYR8LEmLAc6I=; b=Z+cnOpbZ/IpnzQ08J2ugLjOmihljfTWMojc/IOf1Q8VfiHcRz2HK24boxB8Jyh0DJ5 oWbqSvA5SikXc2QZOhI3BhI2SSZn1vLHIeWu+UMFgBbURGeAhFvdoYtUBF3ZAiGZ+lEt h3G1fPqJKcVw0JwJ0czmUq8p4altZxexgQ8Rqg3OF5mKgmZkxLjaIeiP+9fbJcqriM+V YPWbU97ZDlTLaHRdhW+Ljtys+1DphZ4AtCh7FrlHnFKdeNEoVkWMxU/rxpYPMKOCMSTe UW7UfFTnxF3DMaq0zNCdnKMULS0dH+WQahniQliiRO9IWJmo7JVAsRBF9k1JbSl4fcs9 N4+g==
X-Gm-Message-State: AMke39k+C+qr9XQAbWX8Bb5EKKlYvkFA6pXHhMKG2Ts2s+r8GowQbWPh75RGQa6Udp5J7z9krRRB8gxJiE1O3r86
X-Received: by 10.237.34.250 with SMTP id q55mr29905491qtc.127.1487087106149; Tue, 14 Feb 2017 07:45:06 -0800 (PST)
MIME-Version: 1.0
References: <CABdrxL6qupAu+Ztxw7BU1e-eoy-kfJKRQq+ZZyoKokXHNZEoZQ@mail.gmail.com> <local-bdf4ca0e-d529@nylas-mail.nylas.com>
In-Reply-To: <local-bdf4ca0e-d529@nylas-mail.nylas.com>
From: David Benjamin <davidben@chromium.org>
Date: Tue, 14 Feb 2017 15:44:55 +0000
Message-ID: <CAF8qwaBQOfW68BcyG_d6wNsGTT+e6XajEYd0OSjjDekEQOD2mw@mail.gmail.com>
To: David Wong <davidwong.crypto@gmail.com>, Cas Cremers <cas.cremers@cs.ox.ac.uk>
Content-Type: multipart/alternative; boundary="001a113eea5ab6b8d805487f72b4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RHnkIs6nEAbiiDqZmEOqe7qDQ4Y>
Cc: tls@ietf.org
Subject: Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18
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: Tue, 14 Feb 2017 15:45:09 -0000

NewSessionTicket always includes in-handshake client auth. The resumption
secret can't even be derived without it.

On Tue, Feb 14, 2017 at 10:21 AM David Wong <davidwong.crypto@gmail.com>
wrote:

> I can see this problem even in the case where the client sends an empty
> Certificate message during the handshake. If the application does not tell
> the client what happened, a NewSessionTicket has no way of indicating if it
> will include client-auth in the next session.
>
> David
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>