Subject: Re: PEP ID terminology

From: borderlt <[email-masked]>
Date: Sat, 12 May 2001 10:56:01 -0400

Steve,

    I am copying the response to the PILC list because the document has
already been approved by the IESG and is somewhere between the IESG and the
RFC Editor so changes have procedural implications.  I am not necessarily
opposed to a change if there is consensus but I think the change probably
requires more than a global replacement of "transport layer security" with
"session layer security".  Even if it is wrong, I think our use of the term
is consistent with how most people use it so, if we change, we will have to
add some explanation.  (And, if our use is consistent, I don't think that this
document is the place to start correcting this use without explanation.)

    The first thing, though, is that I want to make sure that I understand
your comments correctly...

    My initial reaction was "Doesn't this definition mean that IPsec is
transport layer security?"  After reading your comments a little more closely,
though, I think the distinction might be related to how it is implemented. 
Applications (I think) must specifically invoke TLS (or SSL) rather than
invoke TCP.  Whereas, with IPSec, the higher level protocol, e.g. TCP, does
not explicitly invoke IPsec (even though the API may have changed when IPsec
was added to the IP layer).  Is my understanding of the distinction you are
making correct?

John

Stephen Kent wrote:
> 
> Folks,
> 
> I recently skimmed your ID on PEP.  In it you refer to transport
> layer security on a number of occasions. Despite the name associated
> with the IETF standard "TLS"  and with its WAP counterpart (WTLS)
> these are NOT transport layer security protocols. They are session
> layer security protocols, i.e., they protects application data before
> that data is passed to the transport layer. TLSP is an example of a
> transport layer security protocol, but it is not used today and thus
> not of much interest or relevance to you document.  You might want to
> change references to "transport layer security" in your ID to
> "session layer security."
> 
> Thanks,
> 
> Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 May 2001 17:28:57 -0400

>was added to the IP layer).  Is my understanding of the distinction you are

John,

I don't mean to pick on the PEP document unfairly, but rather to 
point out, again, that this terminology error is being compounded in 
yet another document seeking RFC status. I recently reviewed a book 
manuscript with the same error. Still, I persist in trying to fix 
this problem.

This is not a matter of local implementation, but I can understand 
the confusion, and the ISEG decision long ago to label TLS as 
"transport later security" was an error which keeps haunting me. I'll 
explain the reasoning that leads one to characterize IPsec as an IP 
layer security protocol, and TLS/SSL as a session layer security 
protocol.

IPsec processes IP layer headers and can encapsulate entire IP 
datagrams, or transport layer "packets." AH, one of the two IPsec 
protocols, generates an IP header option. Thus, IPsec is an IP layer 
security protocol, which is independent of the transport layer 
protocol used above it. One cannot implement IPsec entirely above IP 
and hand down an IPsec PDU for transmission by IP. Rather, one 
integrates IPsec INTO an IP implementation, or intercepts an already 
formed IP packet (in a BITS, BITW or security gateway implementation) 
and processes it, to effect IPsec.

In contrast, TLS/SSL creates its own notion of sessions (and 
connections) ABOVE TCP, consistent with what a SESSION protocol 
(security or otherwise) would do. The output of TLS/SSL is handed 
down to TCP for transport, just as would any  higher layer protocol 
interfacing to TCP. Usually in the TCP/IP suite, the next protocol 
layer is the application, but TLS/SSL is not an application and its 
behavior is that of a session protocol, which is the next layer up 
from the transport layer in the OSI suite. TLS/SSL does not ever have 
access to TCP layer headers (contrast with with the IPsec processing 
and manipulation of IP headers). For all of these reasons, TLS/SSL is 
NOT a transport layer protocol.

Steve

---

From: Joe Touch <[email-masked]>
Date: Tue, 15 May 2001 10:22:24 -0700

Stephen Kent wrote:
> datagrams, or transport layer "packets."

I thought IP was network layer, and TCP and UDP were transport.

Joe

---

From: Allison Mankin <[email-masked]>
Date: Thu, 17 May 2001 22:50:12 -0400

Hi, Steve,

I do understand how a misleading term can cause distress (don't
get me started on the many ways people use the term signaling).

But one point that might decrease the offense that transport
layer security seems to be giving is that, in constrast to OSI,
the Internet's transport protocols have tended to be combined
transport and session (layer 4 and at least part of layer 5).
So it doesn't strike me as quite that outrageious that a protocol
with no layer four functions might still be loosely termed as part
of transport, if it is performing session functions.

About the language in the PEP spec, the authors are right that
this one is about to go to the RFC Editor.  But I think we could
perform very minor language clarification in the final editing stages.

I agree with John Border, though, that substituting "session layer
security" in this document will not make a clear statement to
the reader.  Perhaps referencing it as "session-layer security over 
transport, such as with SASL or TLS" would do the trick.  Please
advise.

Allison

P.S. It doesn't help the situation that a Security Area WG on this
topic is called Transport Layer Security and has produced TLS.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 22 May 2001 09:02:56 -0400

>of transport, if it is performing session functions.

I've tended to think that we have pushsed session layer functions 
into applications, rather than down into the transport layer. FTP is 
a prime example, and HTTP may be one too. Also, we have several new 
protocols looking to become IETF standards that explicitly name 
themselves as session protocols, making it clear that we are 
acknowledging the utility of a session layer in some contexts.

>transport, such as with SASL or TLS" would do the trick.  Please

Yes, that phrase is a good one.

>topic is called Transport Layer Security and has produced TLS.

Absolutely! I bugged Jeff about this a few years ago, when the TLS WG 
was formed, but he suggested that there was some political reason for 
the name.  Recall that TLS was formed when Microsoft and Netscape 
came to the IETF and asked us to referee a fight over the next 
generation security protocol for use with HTTP. MS had some proposals 
for what were application layer enhancements, analogous to SHTTP, 
while Netscape just wanted to improve on SSL.