Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman <[e-mail]>]

The use case for the D(TLS) Path Validation extension in civil aviation has
been submitted
https://www.ietf.org/archive/id/draft-segers-tls-cert-val-ext-use-case-00.txt
there
is also referenced slide deck available
http://conceptsbeyond.com/resources/SCVPValidationRequest_UseCase_CB.pdf

Thank you,
Ashley Kopman

On May 26, 2022, at 8:36 AM, Ashley Kopman <[e-mail]>
wrote:

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