Got it. 1. So we should not try to support DTLS and CTLS at the same time. As you say, it’s a breaking change. so it’s better to have two "dedicated" implementations.
2. You’ve mentioned profile_ids of 4 bytes being "well known”. We wait for IANA to open a new registry for this, right? Thanks. K > On 4 Jan 2023, at 15:07, Ben Schwartz <bem...@google.com> wrote: > > Coalescing threads. > > On Wed, Jan 4, 2023 at 6:09 AM Kristijan Sedlak <xpeperm...@gmail.com > <mailto:xpeperm...@gmail.com>> wrote: >> CTLS looks interesting. >> >> 1. Is it too early for us developers to start working on implementations? > > Now is a great time to start on an implementation! > >> 2. Is this the way where UDP-based TLS is going in general or is it just yet >> another experiment built for specific use cases and is not intended for >> general use? Will cTLS be the new dTLS? > > cTLS is not limited to UDP. However, for both UDP-like and TCP-like use > cases, cTLS represents a breaking change compared to TLS and DTLS. As such, > it cannot be deployed via a transparent upgrade like TLS 1.x and DTLS 1.x. > Use is limited to cases where the client knows in advance that the server > supports a specific cTLS profile (and the benefits of cTLS have been judged > to justify the additional complexity). > >> Can we expect long-term support from IETF? > > The IETF doesn't really provide "support", just documentation. However, if > cTLS does become a "Proposed Standard", it is likely to remain so for many > years. > > On Wed, Jan 4, 2023 at 6:12 AM Kristijan Sedlak <xpeperm...@gmail.com > <mailto:xpeperm...@gmail.com>> wrote: > ... >> The spec states that a client needs to inform the server about the profile >> it is planning to use (profile_id in the record's header). Does this mean >> that endpoints should all share the same knowledge about available profiles >> or is there a predefined list of profiles provided by IETF? > > profile_ids of 4 bytes and less are "well known", and must be registered with > IANA. Note that this registry can expand over time, so neither party can > assume that the other party understands a profile_id just because it is > registered, as the other party might have last been updated before the > profile_id was registered. > > Longer profile_ids are not subject to registration, and may have different > meanings in different contexts. > >> How will the profile system work on the open internet? > > I see cTLS being used in three different ways: > > 1. By private arrangement, like an embedded device whose firmware includes a > particular profile. > 2. By standards action, like in a future version of QUIC that specifies a > cTLS profile to use for the embedded TLS handshake > 3. By negotiation. For example, two WebRTC peers could negotiate a cTLS > profile during connection setup. > > This specification only covers #1. The other two paths will require > additional standards work, but that work will probably only happen once we > have some implementation experience with cTLS.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
