Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman <[e-mail]>]

Ilari,

Thank you for your feedback.

You are correct in assuming that this was designed after the OCSP status_request extension. It is a valid point that the extension can likely be omitted from the server hello. The intent was to communicate to the client that the server supports the extension and will respond with the path validation information. However, since it is allowed for the server to respond with the extension and then not supply the path validation, it is not very useful overhead. I will remove the extension from the server hello.

You are also correct that sending the certificate chain becomes unnecessary. It was my intent to communicate that, but looking back at the draft, I don’t think I made it clear. I will add it.

Thank you,

Ashley


> On May 25, 2022, at 2:23 PM, Ilari Liusvaara <[e-mail]> wrote:
> 
> 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