On Wed, Jan 4, 2023 at 9:37 AM Kristijan Sedlak <xpeperm...@gmail.com> wrote:
> 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. > In general, I would expect cTLS implementations to be part of a codebase that also implements TLS and DTLS, roughly like a third protocol variant. > 2. You’ve mentioned profile_ids of 4 bytes being "well known”. We wait > for IANA to open a new registry for this, right? > The draft specifies the initial registry contents, so we can use that in addition to the null profile and "long" custom profiles. > > 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> > 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> > 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. > > >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
