Re: [TLS] Review of draft-guballa-tls-terminology-03

["Schwarz, Albrecht (Nokia - DE)" <[e-mail]>]

Hello Eric,

thanks for starting the discussion in getting the TLS and DTLS terms clarified and fixed!
Just a quick reply today on the overall approach before commenting (or my colleagues) on the individual terms.

1st There are two groups working on (D)TLS specifications: the inner circle of TLS experts which might share a common understanding about the protocol semantics behind a term (this group might be WG TLS and perhaps also UTA); - and there is outer circle refering to (D)TLS in signalling plane, management plane, control plane, application and service specifications etc (such as WGs MMUSIC, RTCWEB, PERC, etc etc and SDOs like ITU-T, 3GPP, OMA, etc etc).
I'm belonging to the second group, lacking that insider knowledge to the TLS experts community.

2nd Definition A vs B for Term X
When using statements "make things clearer / worser than ..." then we need to look at the comparison of A and B.
Now, "A" is (often) not available (or somehow hidden in the existing (D)TLS RFCs, or only described at high level) when "B" relates to the terminology draft.

Furthermore, related the considered set of terms:
We need firstly fixe the terms for the TLS and DTLS "basic protocol set" (see the list of referrenced RFCs in the draft). The usage of them in context of ICE (and the interessting question of ICE restarts), WebRTC, tunnel techniques, etc should be considered in a subsequent step. Either an original term remains unchanged or would need to be further qualified.
But a consideration of "open, forward compatiblity" term semantics will lead in the end to a very vague definition in my understanding.
And it should be feasible to fix these terms because we got concrete information and data models behind the (D)TLS protocol entities. It's merely a question about the concrete set of information behind a particular term.

With regards to hierarchy:
The concept of (D)TLS in separating "session" and "connection|association" level, as well as protocol procedures at the very beginning and during the communication phase represent actually an hierarchical model inside the protocol.
Thus, the terminology draft follows that hierarchical approach (which again should leads to concise individual term definitions).

Regards, Albrecht



From: TLS [mailto:[e-mail]] On Behalf Of EXT Eric Rescorla
Sent: Dienstag, 26. April 2016 19:46
To: [e-mail]
Subject: [TLS] Review of draft-guballa-tls-terminology-03

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.