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
