I recently reviewed draft-guballa-tls-terminology-03. Comments below. OVERALL I'm sympathetic to concerns that TLS terminology may not be as precise as one would like, but IMO this document doesn't make things significantly clearer and in some cases makes it worse. Specifically:
- (D)TLS is intentionally defined without any tight binding to the underlying transport. However, this document tries to tie it to IP semantics, which is not helpful and doesn't match existing practice. - This document introduces a number of terms that don't exist in the (D)TLS documents (e.g., "Transient (D)TLS session"). This is just going to cause confusion. In general, I don't think that having a second document that acts as a glossary for (D)TLS but isn't part of the main documents is going to help much. If the authors feel like the terminology in TLS is imprecise, it would be more helpful to suggest changes to TLS 1.3 (e.g., via PRs). DETAILED COMENTS S 3.1.1. There's no restriction on TLS that a given endpoint is attached to one IP address, and in fact, it's common to run DTLS in multihomed configs (e.g., DTLS over ICE). S 3.2.1. Again, (D)TLS isn't bound to the port or IP. S 3.2.2. This whole notion of semi-permanent versus transient isn't helpful, especially in the face of tickets. S 3.2.2. This is just a new invented term. Please don't S 3.3.1. Destruction point doesn't seem useful since in many cases it's "unknown" since it's in the future S 3.3.4. In DTLS you can respond to a ClientHello with a HelloVerifyRequest as well. S 3.4.4. "message sequence" seems invented. S 3.4.7. I don't think it's helpful to import ITU notions of connection state here, especially in the face of stuff like false start. S 3.4.12. Copying the session state here doesn't seem that useful, especially splitting it into two states.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
