Re: [TLS] Draft TLS Extension for Path Validation

[Ashley Kopman]

Version -01 of this draft has been submitted 
https://www.ietf.org/archive/id/draft-segers-tls-cert-validation-ext-01.txt 


It incorporates updates based on the comments we have received so far.
Limit this to (D)TLS 1.3, removed (D)TLS 1.2
Removed extension from Server Hello, only included in Client Hello and 
Certificate messages
Make clear that the server does not need to send the certificate chain when 
sending an SCVP response, only the end-entity certificate.
Thank you to everyone who has provided feedback.

Ashley Kopman


> On Jun 1, 2022, at 9:42 AM, Ira McDonald  wrote:
> 
> 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  > 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 > > 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 > > 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 >>> > 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 wil

[TLS] Fwd: New Version Notification for draft-moskowitz-lpwan-ipnumber-00.txt

[Robert Moskowitz]

Here is my draft for asking for an Internet Protocol Number assigned to 
SCHC as we have been discussing on both the Ipsecme and Tls lists.


I also posted this to the lpwan list.

I welcome comments and help (co-authors welcomed!).

Bob



 Forwarded Message 
Subject: 	New Version Notification for 
draft-moskowitz-lpwan-ipnumber-00.txt

Date:   Fri, 03 Jun 2022 08:33:59 -0700
From:   internet-dra...@ietf.org
To: Robert Moskowitz 




A new version of I-D, draft-moskowitz-lpwan-ipnumber-00.txt
has been successfully submitted by Robert Moskowitz and posted to the
IETF repository.

Name: draft-moskowitz-lpwan-ipnumber
Revision: 00
Title: IP Number for SCHC
Document date: 2022-06-03
Group: Individual Submission
Pages: 6
URL: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.txt
Status: https://datatracker.ietf.org/doc/draft-moskowitz-lpwan-ipnumber/
Html: https://www.ietf.org/archive/id/draft-moskowitz-lpwan-ipnumber-00.html
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-moskowitz-lpwan-ipnumber



Abstract:
This document requests an Internet Protocol Number assignment for
SCHC so that SCHC can be used for IP independent SCHC of other
transports such as UDP and ESP.



The IETF Secretariat

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls