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

[Eric Rescorla <[e-mail]>]

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

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

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



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

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


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

But this isn't a TLS concept.

-Ekr


>
> *Thanks,*
>
> *Jens*
>