Re: [TLS] Review of PR #209
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Wed, 16 September 2015 18:25 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
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 31EEE1A8863 for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 gG0j8NMJRKPz for <tls@ietfa.amsl.com>; Wed, 16 Sep 2015 11:25:07 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564AA1A886E for <tls@ietf.org>; Wed, 16 Sep 2015 11:25:02 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 2775E1A25C8; Wed, 16 Sep 2015 21:25:00 +0300 (EEST)
Date: Wed, 16 Sep 2015 21:25:00 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Martin Thomson <martin.thomson@gmail.com>
Message-ID: <20150916182459.GA15546@LK-Perkele-VII>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com> <20150916153041.GA14682@LK-Perkele-VII> <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABkgnnVbJvFQ217Yq7eVLV+_cuQOUVoi1Ydixq5zBC9Zju1U-g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Dp4fCULxEXFl_SgoEi6UnqV7kwc>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Review of PR #209
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: Wed, 16 Sep 2015 18:25:10 -0000
On Wed, Sep 16, 2015 at 10:48:27AM -0700, Martin Thomson wrote: > On 16 September 2015 at 08:30, Ilari Liusvaara > <ilari.liusvaara@elisanet.fi> wrote: > > Problem with pulling client auth out of the handshake is that it > > complicates applications that can't change identities involved with > > active connection. > > Why would that be unsupported here? The server can still send > CertificateRequest immediately after its Finished. That looks exactly > like it does today, only the order has changed. > > > As then the application needs to ensure that the authentication > > occurs between TLS handshake and actually starting up the protocol. > > I'm not sure that is necessarily a problem. If the claim is that the > authentication attests to everything prior to its appearance, then you > have no problem. I think that claim is reasonable, but I'm happy to > discuss it. I think it is the attesting (even of present in-flight requests) that is the problem, not not attesting something. > > CertificateRequest contains the permitted signature algorithms > > for the PoP signature, which TLS library needs to verify before > > dumping the certificate chain on application (which can then > > figure out things like trust anchors). > > > > Without CertificateRequest, one has little idea what algorithms > > are acceptable there. > > Arguably, signature_algorithms covers that adequately. Though I'll > grant that certificate chain validation often happens in a separate > component to the TLS stuff. The extension? IIRC, that is what _client_ can verify. This is about what _server_ can verify. Or the equivalent of current field that specifies that? That's inside CertificateRequest, which would be optional. -Ilari
- [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Eric Rescorla
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Karthikeyan Bhargavan
- Re: [TLS] Review of PR #209 Ilari Liusvaara
- Re: [TLS] Review of PR #209 Martin Thomson
- Re: [TLS] Review of PR #209 Daniel Kahn Gillmor
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 henry.story@bblfish.net
- Re: [TLS] Review of PR #209 Andrei Popov
- Re: [TLS] Review of PR #209 Geoffrey Keating
- Re: [TLS] Review of PR #209 Henry Story