Re: [TLS] Defining "TLS channel"

[Nicolas Williams <[e-mail]>]

On Mon, Dec 07, 2009 at 09:17:12PM +0000, David-Sarah Hopwood wrote:
> [e-mail] wrote:
> > Well, I think one thing we've learned here is that none of the
> > reasonable-looking definitions of "TLS channel" are exactly what
> > typical TLS libraries offer to applications (via their APIs -- and
> > there's some variation between APIs, too).
> 
> I would expect a definition of "TLS channel" to inform the design of
> new APIs or API abstractions. I wouldn't expect it to change existing
> abstractions in current APIs, except possibly those that already have
> an abstraction that almost-but-not-quite corresponds to a TLS channel,
> and where the change to make it exactly correspond can be done compatibly.

Look at draft-altman-tls-channel-bindings.  The impact on APIs is really
rather trivial.  All APIs will have some sort of handle to a TLS
connection.  A connection is almost a channel.  From a connection you
need a way to extract the channel bindings.

Now, the only question is: is a series of connections resulting from
re-negotiations one channel?  Or is a channel == to a connection?

(Here I'm using "connection" to mean something that's barely referred by
that name in RFC5246, but which is: the state established by a TLS
handshake and the record layer messages exchanged under its protection.)

SSHv2 also does re-negotiations, but with proper binding of
re-negotiations to the prior state.  SSHv2 even has a proper unique
channel binding: SSHv2 session IDs (which are derived by hashing all
negotiation and key exchange messages).  The SSHv2 session ID does not
change even when re-negotiations occur.

>From an RFC5056 point of view, the SSHv2 view is the correct one.  The
application sets up a channel, runs some additional application-layer
authentication mechanism over that channel with channel binding to that
channel, and then proceeds.  It would be most unfortunate if after the
authentication + channel binding operation the channel could be
replaced, without the app's knowledge, with another one that might have
an MITM.

> > Also, different people seem to have somewhat different expectations
> > what properties such a "channel" should have. For example, if the
> > certificate of peer changes in renegotiation, is that just a different
> > certificate for the same identity, or a different identity? Does the
> > application need to determine which received application_data byte
> > corresponds to which certificate?
> 
> The abstraction of "channel" most useful for understanding the attack
> and the authentication properties of TLS, is one such that every
> completed handshake begins a new channel -- whether or not there are
> changes in identity information, and independent of whether the
> handshake is abbreviated or full.

For understanding the attack, yes.  But see below.

> (I was mistaken in claiming earlier that only full handshakes should
> be considered to start a new channel. Any pair of Finished messages
> creates a new channel identifier, and therefore should be considered
> to create a new channel.)

Prior to fixing the re-negotiation vulnerability we should have
considered each negotiation as resulting in a separate channel: then
applying channel binding as an analysis tool would have made the MITM
problem instantly apparent.

Following the fix to the re-negotiation vulnerability I think we should
say that the first negotiation establishes a channel and that the
subsequent ones do not, just as in SSHv2.

> > Either way, I don't think we need to answer the question about 
> > RFC5056 "channel" in draft-ietf-tls-renegotiation.
> 
> I disagree; the draft currently uses the term "channel" in the
> Introduction without defining it. It does reference
> draft-altman-tls-channel-bindings, but this isn't sufficient
> to define the term because 'It is inappropriate to use
> Internet-Drafts as reference material or to cite them other than
> as "work in progress."'.
> 
> The draft could, however, informatively cite RFC5056. I think it
> should.

I don't care which I-D introduces a proper definition of "TLS channel",
but I do care to see RFC5246 updated by whichever I-D does it.

Nico
--