Re: [TLS] Draft TLS Extension for Path Validation
Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 25 May 2022 18:23 UTC
Return-Path: <ilariliusvaara@welho.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 60C65C2CEAA1 for <tls@ietfa.amsl.com>; Wed, 25 May 2022 11:23:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgGVeRVaZ7Iy for <tls@ietfa.amsl.com>; Wed, 25 May 2022 11:23:36 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4b.welho.com [83.102.41.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBEE2C2CEAA0 for <tls@ietf.org>; Wed, 25 May 2022 11:23:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3144267D73; Wed, 25 May 2022 21:23:32 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id oQwLiFKaLPEs; Wed, 25 May 2022 21:23:31 +0300 (EEST)
Received: from LK-Perkele-VII2 (87-92-216-160.rev.dnainternet.fi [87.92.216.160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8AE9A7A; Wed, 25 May 2022 21:23:29 +0300 (EEST)
Date: Wed, 25 May 2022 21:23:29 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Ashley Kopman <akopman@conceptsbeyond.com>
Cc: tls@ietf.org
Message-ID: <Yo50IQhyJM/VABlL@LK-Perkele-VII2.locald>
References: <2790C640-0841-43BC-94CA-0890ECEA672A@conceptsbeyond.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <2790C640-0841-43BC-94CA-0890ECEA672A@conceptsbeyond.com>
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/5dpE_0uWRhbL9A0ZW6IrokSnF7g>
Subject: Re: [TLS] Draft TLS Extension for Path Validation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.34
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, 25 May 2022 18:23:39 -0000
On Wed, May 25, 2022 at 12:40:13PM -0400, Ashley Kopman wrote: > Hi TLS, > > I have just submitted a draft TLS Extension for Path Validation > https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt <https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-00.txt> > > The proposal is for a Path Validation Extension to provide a new > protocol for TLS/DTLS allowing inclusion of certificate path > validation information in the TLS/DTLS handshake. Specifically, it > covers the use of Server-based Certificate Validation Protocol > (SCVP) for path validation. Looking at how this is integrated to (D)TLS: For (D)TLS 1.2, the server extension does not seem to be technically necressary, and omitting it could simplify things. Yes, this design is the same as one used for OCSP stapling (status_request), but I found the server hello extension in OCSP to be seemingly unnecressary extra complexity. For (D)TLS 1.3, why there are seemingly two server extensions, one in server hello, which is usually only used for low-level crypto stuff, which this is not, and another in certificate message (which makes sense for certificate-related thing. And this is maybe a stupid question, but I didn't find an answer by quickly looking at the draft nor the SCVP RFC, does the server need to send the certificate chain to the client if it sends the SCVP response, or just the end-entity certificate? Omitting the chain could save quite a bit of handshake size. -Ilari
- [TLS] Draft TLS Extension for Path Validation Ashley Kopman
- Re: [TLS] Draft TLS Extension for Path Validation Robert Moskowitz
- Re: [TLS] Draft TLS Extension for Path Validation Ilari Liusvaara
- Re: [TLS] Draft TLS Extension for Path Validation Peter Gutmann
- Re: [TLS] Draft TLS Extension for Path Validation Robert Moskowitz
- Re: [TLS] Draft TLS Extension for Path Validation Robert Moskowitz
- Re: [TLS] Draft TLS Extension for Path Validation Ashley Kopman
- Re: [TLS] Draft TLS Extension for Path Validation Salz, Rich
- Re: [TLS] Draft TLS Extension for Path Validation Ashley Kopman
- Re: [TLS] Draft TLS Extension for Path Validation Robert Moskowitz
- Re: [TLS] Draft TLS Extension for Path Validation Eric Rescorla
- Re: [TLS] Draft TLS Extension for Path Validation Ashley Kopman
- Re: [TLS] Draft TLS Extension for Path Validation Ira McDonald
- Re: [TLS] Draft TLS Extension for Path Validation Ashley Kopman