Hi Ashley, Bear in mind that DTLS 1.3 languished in the RFC Editor's queue for over a year.
The major TLS libraries have had implementations and have been doing interop testing for a long time. Simply doing software update to current library versions would make DTLS 1.3 available in civil aviation. FWIW - The Common Criteria standard workgroup for Network Devices (routers, switches, etc.) has approved the mandatory requirement for DTLS 1.3 in their next version (draft in July 2022 for publication in fall 2022). Cheers, - Ira On Tue, May 31, 2022 at 12:32 PM Ashley Kopman <[email protected]> wrote: > Eric, > > Thank you for your comments. > > My initial concern with limiting this to (D)TLS 1.3 was that the DTLS 1.3 > RFC has just been released and support is not yet widely available. > However, our use case is for civil aviation and it will take time for the > community begin using it. By that time there should be sufficient support > for DTLS 1.3. I believe it is possible to limit this to (D)TLS 1.3. I will > make the update to the draft. > > Thank you, > > Ashley > > > On May 28, 2022, at 5:27 PM, Eric Rescorla <[email protected]> wrote: > > I took a quick look at this draft. A few comments follow. > > > VENUE > The correct venue for this work is the TLS WG. This is a relatively > straightforward piece of work that is clearly within the TLS WG's > charter scope ("This includes extensions or changes that help > protocols better use TLS as an authenticated key exchange protocol"). > To that end, I don't think we need a BOF or SECDISPATCH. I would > encourage you to ask for TLS WG time in PHL. > > > TECHNICAL > In general, we are trying to avoid extending (D)TLS 1.2, so it would > be good if we could limit this to (D)TLS 1.3. Is that possible? > > I realize that the certificate_status message extension includes a new > message, but I think that's proven to be kind of an anti-pattern. > If you are going to put this in (D)TLS 1.2, I would just put it in > a ServerHello extension, which more closely parallels (D)TLS 1.3. > > If you use extensions, then you can register them with Specification > Required, which would allow you to publish in the Independent Stream > (or some other venue) to register the code points should the TLS > WG choose not to take up this work. > > -Ekr > > > > On Thu, May 26, 2022 at 4:53 PM Robert Moskowitz <[email protected]> > wrote: > >> 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 <[email protected]> >> 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 <[email protected]> >> 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 [email protected]https://www.ietf.org/mailman/listinfo/tls >> >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
