Re: [TLS] Draft TLS Extension for Path Validation

[Robert Moskowitz <[e-mail]>]

This is the Aviation use case I mentioned in earlier mails.

I will be submitting a BOF request tomorrow, performa.

Of course it is for the ADs to decide if this is a standalone BOF or a 
20min slot in SECDISPATCH.

How much time people want to discuss it is in large measure related to 
the discussion we engender here.

Thank you for your attention.  And thank you for reviewing and making 
this a solid design that we can get deployed for avaiation Air-to-ground 
and any similar use case.

Bob

On 5/26/22 19:43, Ashley Kopman wrote:
>
> 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
>>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls