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