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> Wed, 15 February 2017 19:52 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 E005D1297AA for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 11:52:39 -0800 (PST)
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, 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, URIBL_BLOCKED=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 q4YoXq7fURok for <tls@ietfa.amsl.com>; Wed, 15 Feb 2017 11:52:38 -0800 (PST)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 1148412978B for <tls@ietf.org>; Wed, 15 Feb 2017 11:52:38 -0800 (PST)
Received: by mail-qk0-x231.google.com with SMTP id p22so70475683qka.0 for <tls@ietf.org>; Wed, 15 Feb 2017 11:52:37 -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=a3K9rIVaJV5gPMpXNXL7HKFwN4qCwD+4z0c2j55gxhY=; b=ioZIbga+flarvSoL4cYgxg9HT4mHqIFTr7batLNc8VO37ubayJtMZiX54h5IGav4bO NSLCocQahms1r98PLbUrv/52eJA7TgZa4yx19ZYy0VkKBmdNGpqs1/9G2vREr0ix3Kor Ud8/HILYdV61kFb+gYNekxDPCr58SjwdOFAEE=
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=a3K9rIVaJV5gPMpXNXL7HKFwN4qCwD+4z0c2j55gxhY=; b=e6KYm6xy1l6kLZftNp6zA+WK3NWOEgRQpBhdgRGFj5ji8ryg/szx2DGHrXhQoqAC3d 3ndWqIkFpcxw6E8TbNUUxsV4tVqCbSmSGOy+L2XElPl0XxGzZsvkI1E25h0oGZePoLgc 9fM7/GMqI+lSWkSb6/5C9c+K+r8Z9rZz5XaX0KPiTklWR8vH2RI27fHEW5Pv67Bksbu9 DBCNVdweg/QnHJvrJ7WWrqBSOVDb+axteytweA3e1JjaKjo/t+WQ10i2PHlCKHwXlpvt 94N4MY8l7P1R0WrHWO6/KERZMXu318YiO2zWJe57lX8vfYuzh5iYPNsnh6BmppwF1CEq ajjQ==
X-Gm-Message-State: AMke39keEi0CBcJfXw/ESBoBnVkSUgm2SkXzGCShzh6NCH637yBdXuZ07QGqVq8D7tTvfNYqaWEtersZQJvJ01kL
X-Received: by 10.55.22.74 with SMTP id g71mr19078335qkh.40.1487188356970; Wed, 15 Feb 2017 11:52:36 -0800 (PST)
MIME-Version: 1.0
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> <CY1PR0301MB08426CD005E640B9865D1BC38C580@CY1PR0301MB0842.namprd03.prod.outlook.com> <local-4715c433-f49c@nylas-mail.nylas.com> <CY1PR0301MB0842A7DE42636FD4FAD393F18C5B0@CY1PR0301MB0842.namprd03.prod.outlook.com> <local-dd07e89e-e724@nylas-mail.nylas.com>
In-Reply-To: <local-dd07e89e-e724@nylas-mail.nylas.com>
From: David Benjamin <davidben@chromium.org>
Date: Wed, 15 Feb 2017 19:52:26 +0000
Message-ID: <CAF8qwaB+CJof9sk7+Yt=iFdPeA6dTLeph9hsQ1d=HUCOHg2y5w@mail.gmail.com>
To: David Wong <davidwong.crypto@gmail.com>, Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: multipart/alternative; boundary="001a11474584bbb0f805489705c2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xjEjHQu8UIqJXXPEdx-Mykfr3RM>
Cc: Cas Cremers <cas.cremers@cs.ox.ac.uk>, 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: Wed, 15 Feb 2017 19:52:40 -0000
On Wed, Feb 15, 2017 at 2:49 PM David Wong <davidwong.crypto@gmail.com> wrote: > On Feb 15 2017, at 7:27 pm, Andrei Popov <Andrei.Popov@microsoft.com> > wrote: > > Yes, I agree that it is useful to mention this in the spec. > > > > > It would be nice is to have two different PRs solving this issue. One > mentioning this as a potential issue that the application must be aware of. > I've seen things like that for example in rfc 5746: > https://tools.ietf.org/html/rfc5746#section-5 > > > While this extension mitigates the man-in-the-middle attack described > in the overview, it does not resolve all possible problems an application > may face if it is unaware of renegotiation. For example, during > renegotiation, either the client or the server can present a different > certificate than was used earlier. This may come as a surprise to > application developers (who might have expected, for example, that a > "getPeerCertificates()" API call returns the same value if called twice), > and might be handled in an insecure way. > > A second PR could try to tackle this by adding a new message, for example > an "AcknowledgeClientAuthentication" message that the server would send to > confirm (or not) the validation of the client certificate. I think this > would add a bit of complexity for less "surprise". I'm not too keen on > this, and I think this could be added as an extension instead, but I think > it would be nice to have to see if it integrates nicely in the current > draft. > Post-handshake auth exists basically entirely to service HTTP/1.1 reactive client certificate which was previously hacked on via renegotiation. I think we should not make this feature any more complicated than absolutely necessary to support this mode, and we should not add more bells and whistles to it to encourage further use. For the HTTP/1.1 use case, this is not necessary because it's reasonable for client/server to agree that the server will not send any more data for that request until it has processed the client's authentication messages. David
- [TLS] Awkward Handshake: Possible mismatch of cli… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Victor Vasiliev
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Sam Scott
- Re: [TLS] Awkward Handshake: Possible mismatch of… Eric Rescorla
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Ilari Liusvaara
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Thomson
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex
- Re: [TLS] Awkward Handshake: Possible mismatch of… Cas Cremers
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Wong
- Re: [TLS] Awkward Handshake: Possible mismatch of… David Benjamin
- Re: [TLS] Awkward Handshake: Possible mismatch of… Andrei Popov
- Re: [TLS] Awkward Handshake: Possible mismatch of… Martin Rex