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

From: Eric Rescorla <[email-masked]>
Date: Tue, 26 Apr 2016 10:45:49 -0700

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.

---

From: "Schwarz, Albrecht (Nokia - DE)" <[email-masked]>
Date: Wed, 27 Apr 2016 15:48:27 +0000

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:[email-masked]] On Behalf Of EXT Eric Rescorla
Sent: Dienstag, 26. April 2016 19:46
To: [email-masked]
Subject: [TLS] Review of draft-guballa-tls-terminology-03

OVERALL

- (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.

DETAILED COMENTS
S 3.1.1.

S 3.2.1.

S 3.2.2.

S 3.2.2.

S 3.3.1.

S 3.3.4.

S 3.4.4.

S 3.4.7.

S 3.4.12.
Copying the session state here doesn't seem that useful, especially splitting
it into two states.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 27 Apr 2016 15:51:05 +0000

I share ekr's concern about a separate document defining terms that are needed to understand the official spec.

---

From: Melinda Shore <[email-masked]>
Date: Wed, 27 Apr 2016 10:13:48 -0800

I share the more broadly-stated concern that this draft
introduces terminology and architectural framings that
don't match how things work either in practice or in
existing documents.  I understand that the authors are
looking for a tool to get a better handle on the protocol,
but if there's a need for a clearer terminology section
in a core specification it might best be written by
someone who does have "insider"-level knowledge of
the protocol and how it's implemented, etc.  (I don't
think that need exists, for the little that's worth).

Melinda

---

From: "Guballa, Jens (Nokia - DE)" <[email-masked]>
Date: Fri, 29 Apr 2016 15:35:38 +0000

Hi Eric,

See below.

OVERALL

[JG] I don’t think this is consistently true for all (D)TLS related RFCs. E.g. from RFC5764 (DTLS-SRTP), section 3: “A single DTLS-SRTP session only protects data carried over a single UDP source and destination port pair.” 

The terminology draft has been based on the existing (D)TLS RFC landscape so far and thus intends to represent a status quo. I quite agree that this needs to be revised, given new technologies like WebRTC and “DTLS over ICE”.

  confusion.

[JG] The intended rationale behind those terms: A hierarchical information model has been created first, and the terms defined represent that hierarchy. So even if those terms are not directly used in RFCs they are essential from information model persepctive.

 

DETAILED COMENTS

S 3.1.1.

S 3.2.1.

S 3.2.2.

[JG] The terminology is reflecting the lifetime of a session and is by intention independent on how session resumption is performed (tickets or via base TLS RFC). 

S 3.2.2.

S 3.3.1.

since it's in the future

[JG] That’s a good catch, thanks!

S 3.3.4.

well.

[JG] Again, good catch.

S 3.4.4.

S 3.4.7.

[JG] I see your point, the states are separated in Rx and Tx direction. 

S 3.4.12.

it into two states.

[JG] I see your point for repeating the session state in the draft. But I think the server_address at the client side differentiates both objects.

Thanks,

Jens

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 29 Apr 2016 09:20:36 -0700

On Fri, Apr 29, 2016 at 8:35 AM, Guballa, Jens (Nokia - DE) <
[email-masked]> wrote:

> Hi Eric,
>
>
>
> See below.
>
>
>
> *From:* TLS [mailto:[email-masked]] *On Behalf Of *EXT Eric Rescorla
> *Sent:* Dienstag, 26. April 2016 19:46
> *To:* [email-masked]
> *Subject:* [TLS] Review of draft-guballa-tls-terminology-03
>
>
>
> *[JG] I don’t think this is consistently true for all (D)TLS related RFCs.
> E.g. from RFC5764 (DTLS-SRTP), section 3: “A single DTLS-SRTP session only
> protects data carried over a single UDP source and destination port pair.” *
>
> *The terminology draft has been based on the existing (D)TLS RFC landscape
> so far and thus intends to represent a status quo. I quite agree that this
> needs to be revised, given new technologies like WebRTC and “DTLS over
> ICE”.*
>

Well, this isn't a DTLS requirement, at most it's a 5764 requirement, but
even then,
it's not something we're maintaining.

> *[JG] The intended rationale behind those terms: A hierarchical
> information model has been created first, and the terms defined represent
> that hierarchy. So even if those terms are not directly used in RFCs they
> are essential from information model persepctive.*
>

Yeah, I'm not finding it helpful for comprehension.

> *[JG] The terminology is reflecting the lifetime of a session and is by
> intention independent on how session resumption is performed (tickets or
> via base TLS RFC). *
>
>
>
> S 3.2.2.
>
> *[JG] That’s a good catch, thanks!*
>
>
>
>
>
> S 3.3.4.
>
> *[JG] Again, good catch.*
>
>
>
> S 3.4.4.
>
> *[JG] I see your point, the states are separated in Rx and Tx direction. *
>
>
>
> S 3.4.12.
>
> *[JG] I see your point for repeating the session state in the draft. But I
> think the server_address at the client side differentiates both objects.*
>

But this isn't a TLS concept.

-Ekr

> *Thanks,*
> *Jens*