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

["Guballa, Jens (Nokia - DE)" <[e-mail]>]

Hi Eric,

 

See below.

 

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.

[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”.

 

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

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

                                     

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.

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

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

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

 

 

S 3.3.4.

In DTLS you can respond to a ClientHello with a HelloVerifyRequest as

well.

[JG] Again, good catch.

 

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.

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

 

S 3.4.12.

Copying the session state here doesn't seem that useful, especially splitting

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