IETF Logo Mail Archive

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

Martin Thomson <martin.thomson@gmail.com> Tue, 14 February 2017 23:07 UTC

Return-Path: <martin.thomson@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 A8713129863 for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 15:07:43 -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, FREEMAIL_FROM=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 sWq_eZaKhwNs for <tls@ietfa.amsl.com>; Tue, 14 Feb 2017 15:07:42 -0800 (PST)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 73FD01289B0 for <tls@ietf.org>; Tue, 14 Feb 2017 15:07:40 -0800 (PST)
Received: by mail-qk0-x22e.google.com with SMTP id 11so136703940qkl.3 for <tls@ietf.org>; Tue, 14 Feb 2017 15:07:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m5Gm546lFj5cknf8B7qWiXT9HfP48Ro5AeNKacNOHRE=; b=K2RmUvt2I7/yLQbr4BuVvpxfBIPSTZdA9DrQ63wayez9tiB16qSIi9Ub9DE8Y89CdV us0IifXsyRl5NvjAcXS51jFHEHT29hOcRgz03uANwwGpVqUB9wQQvWwMFL9xQRl+1Wdg wFT5QaUWPJvogy0aY3FXr0trujPUl7B4XuNBZemTJVuWLpnkNxhhjEmwFFmtSbdmG0j+ fpzLNBS3Qx+J2ZrS3+VToOEOkJck4m8Mcl5WQGDegDPufW862A5wlnt13lhGT5csF+/S EtweCUnLlY7F5Ha+xbqTRmfF5u0wignfjlOLn7buqAv2flvlkl82XO6JPSAHTQZSA/FJ 3p+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m5Gm546lFj5cknf8B7qWiXT9HfP48Ro5AeNKacNOHRE=; b=g+oV8UeEDo0yavMUWzev9tx/3lPV2o0ZT4YKgX1BhbbX94OY2JJmmZ7xOVaLTGmCly p2FSB3HKLKJwba1zintMnQUKcXB1KzP5Tv6TkE5IQrxlRtsyqgFeKoMNXSp4UW+k2zXo sj6Jj+zIr5zpxQiV1bLT4Des+gPSf9h73Nl87/ZnfTvDGEP5oEGrft2lKIFzhP1yZVlx pSZJriNStMkfQakdcTb+/+t3x7o4WLXVNEMYWo7AylXznnpG116KYNz1PJVagjrFPglB 7akU/ktFG0q8YsV2bYR+sOeb5aEZyxNL4bWzA41cMcLNCXawMW53l9PLzJnDxxg+iZp0 eQ8A==
X-Gm-Message-State: AMke39nu3e+3RHiMKOZkYs9fSBZyLL4jhnhgKElG9WfqWtYbbXB9IwBSxqCOjy6DSbjsxRHIB+7tuPe1MAAA8Q==
X-Received: by 10.55.17.73 with SMTP id b70mr17749805qkh.202.1487113659710; Tue, 14 Feb 2017 15:07:39 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Tue, 14 Feb 2017 15:07:39 -0800 (PST)
In-Reply-To: <local-a70c902a-5994@nylas-mail.nylas.com>
References: <CABdrxL6qupAu+Ztxw7BU1e-eoy-kfJKRQq+ZZyoKokXHNZEoZQ@mail.gmail.com> <local-bdf4ca0e-d529@nylas-mail.nylas.com> <CAF8qwaBQOfW68BcyG_d6wNsGTT+e6XajEYd0OSjjDekEQOD2mw@mail.gmail.com> <local-a70c902a-5994@nylas-mail.nylas.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Wed, 15 Feb 2017 10:07:39 +1100
Message-ID: <CABkgnnXQH7Mtt49GHETfH8-hSMYmT9AKY7jfEn38hJzN=DqWLQ@mail.gmail.com>
To: David Wong <davidwong.crypto@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IcGOyQrjmE3SkQ06yy4hMA0gmaI>
Cc: Cas Cremers <cas.cremers@cs.ox.ac.uk>, "tls@ietf.org" <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 23:07:44 -0000

On 15 February 2017 at 03:18, David Wong <davidwong.crypto@gmail.com> wrote:
> Oups, my bad. What about if the client do send a certificate, but the server
> decides not to accept it, but goes on with the connection (I think nothing
> in the spec says that the server needs to terminate the connection if the
> client cert is not good).


Then it is up to the server to remember this condition.  If it resumes
and later assumes that the client certificate is in place, then it's a
big problem.  Of course, it's easier to NOT remember a client
certificate, so I expect that failure mode to be rare.

v2.23.0 | Report a Bug | By Email