Subject: Re: [sasl] [TLS] RESOLVED (Re: lasgt call comments (st Call:

From: Martin Rex <[email-masked]>
Date: Mon, 2 Nov 2009 15:59:44 +0100 (MET)

Nicolas Williams wrote:
> 
> Another problem that Larry has is that in his implementation what I call
> a "TLS connection" is called a "security context", and if the
> application re-handshakes (e.g., to authenticate a user) then the result
> is a second security context -- we need to be extra clear that it's the
> client Finished message from the _first_ "security context" that we're
> after.

OooopS.

The session that results from a re-handshake is an entirely new and
independent session from what it started from, it does NOT modify
the state of the original session (as identified by its TLS session ID).

Many SSL protocol stacks, however, will perform the re-negotiation
with the same "context" or API handle -- giving the application caller
impression that the original session is modified.  TLS does _NOT_
have capabilities to modify a session, however.  It will either
resume a cached session as proposed by the client as-is, or it
will go through a full handshake and create a new session
that is entirely independent from previous sessions.

The TLS specs do not describe API semantics, however, only the
network protocol and TLS session state, so your terminology is
IMHO confusing.

> 
> My proposal, then, is this:
> 
> OLD:
> 
>    Description: The client's TLS Finished message (note: the Finished
>    struct) from the first handshake of the connection (note: connection,
>    not session, so that the channel binding is specific to each
>    connection regardless of whether session resumption is used).
> 
> NEW:
> 
>    Description: The client's TLS Finished message (note: the Finished
>    struct) from the first handshake of the application's TLS connection.
> 
>    NOTES:
> 
>    a) If a session is resumed, the client's TLS Finished message from
>       the session resumption handshake is to be used;
> 
>    b) If a client does multiple TLS handshakes in sequence, each
>       protected by the previous one, then the client's TLS Finished
>       message from the first/outermost TLS connection is to be used;
> 
>    c) By "TLS connection" we refer to the TLS connection state, not to
>       any notion of connection of any underlying transport protocols
>       (such as TCP, UDP, SCTP, etcetera).
> 
> I'm not sure that we can make it any clearer.

b) sounds wrong to me.  A renegotiate results in a entirely
new and independent session.

It might be easier to _NOT_ key on the finished message, but on the
master secret instead.

-Martin

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 02 Nov 2009 16:55:48 +0100

> It might be easier to _NOT_ key on the finished message, but on the

That was my conclusion as well, hence
http://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-00
which uses the TLS PRF interface.

For -02 I also added hashing the Finished message, to match the
semantics for connection/session (regardless of its definition) of
draft-altman-tls-channel-bindings, but I'd prefer to avoid it
completely.

/Simon

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Nov 2009 17:35:10 +0100 (MET)

> draft-altman-tls-channel-bindings, but I'd prefer to avoid it

If you refer to the TLS-extractor interface with TLS PRF, that does
unconditionally include the client.random and server.random in the
computation and therefore the output will differ for different
incarnations (resumes) of the same TLS session.  That is 
comparable to keying to the _most_recent_ finished message -- with
__NO__ special cased for TLS session resume and TLS renogiation.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 2 Nov 2009 17:48:44 +0100 (MET)

> client Finished message from the _first_ "security context" that we're

Microsoft's implementation (which could be the one referred to by
Larry's implementation) has a silly design flaw in its TLS renogiation,
and I'm not sure that the previous text is a way to fix it.

It is possible to configure Microsoft IIS in a fashion so that it
will first perform a TLS handshake with a server-only authentication,
and after having received the HTTP request, it will re-negotiate and
ask for a client certificate.

In the ClientHello, the client will send no TLS session ID (since
the purpose is renegotiation -- aka a full TLS handshake.
Microsoft IIS will send back a ServerHello with an entirely new
TLS session ID.  In my TLS clients, I will drop TLS sessions
from the client-side cache for which the server asks for
re-negotiation (actually replace them with the resulting
renegotiated TLS session).

Unfortunately, this doesn't save a TLS handshake on the next
connect, Microsoft IIS will force another renegotiation when
that re-negotiated session is resumed, resulting in yet
another new TLS session.

>From my experience, it is possible to TLS resume both, the original
and the renegotiated session when Microsoft IIS is the server,
and it will force through re-negotiation on both.  So an IIS
configured like that will artificially inflate its server-side
session cache and impose unnecessary re-negotiations on
the TLS client and on itself.

And btw. Channel Binding at the application layer and
transparent TLS-session renegotiation at the TLS layer appear
somewhere between hard-to-do and mutually exclusive--in case
that the TLS session renegotiation happens totally transparent
to the application.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 03 Nov 2009 22:06:39 +1300

>ask for a client certificate.

It's not necessarily a design flaw, AFAIK it's a performance optimisation to 
avoid the server having to maintain state/leave a connection open for an 
arbitrary amount of time while the user fumbles around with smart cards and 
certificates and whatnot.

Peter.

---

From: Martin Rex <[email-masked]>
Date: Tue, 3 Nov 2009 13:43:16 +0100 (MET)

> certificates and whatnot.

I'm sorry if I have explained myself so badly.

I was NOT talking about the closing of the connection while the
client is prompting the user for selection of a client certificate.
That is actually an extremely appreciated feature of MSIE (the Browser),
a point where most other web browsers are broken in that they
stall the server in the middle of a TLS handshake for an indefinite
amount of time while performing user interaction.

I was refering to a design flaw in server-side session caching of
Microsoft IIS (the Server) when it is configured to perform renegotiation
in order to obtain a client certificate after having seen and evaluated
the request.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Nov 2009 16:23:53 -0600

> the state of the original session (as identified by its TLS session ID).

What "oops"?  We need to identify one, and only one, client Finished
message to use.  The name of the thing that that message is related to
is only relevant to writing the text for this channel binding type's
definition.

> network protocol and TLS session state, so your terminology is

All of that is irrelevant.

> new and independent session.

That a renegotiate does that is irrelevant.  What is relevant is that we
want the first Finished message.

> It might be easier to _NOT_ key on the finished message, but on the

Too late for that.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Nov 2009 16:24:51 -0600

> draft-altman-tls-channel-bindings, but I'd prefer to avoid it

I don't agree.  That it's easier to speak of the master secret is not
enough.  The Finished message's construction provides better binding of
the entire negotiation (up to that Finished message), and that's why we
chose it.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Nov 2009 16:20:45 -0600

> in order to obtain a client certificate after having seen and evaluated

Why is that a problem?  The request will have named a document, but if
you're using confidentiality protection then so what?  The client knows
the document name, and so does the server.  Authorization _correctly_
happens when the access request is made.  That the necessary user
authentication step is delayed until authorization is needed doesn't
strike me as a problem -- it's a feature.

After all some documents may have anonymous access, and some may
require user authentication.  If the server requested user
authentication prior to knowing what document the client wants to
access, then it will force an ugly interaction on users that only want
to access documents that require no user authentication.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Nov 2009 16:38:39 -0600

> that the TLS session renegotiation happens totally transparent

In order to do channel binding to TLS channels you MUST have some sort
of interface to TLS, and that interface MUST let you get at, in this
case, the first Finished message (in cleartext) sent by the client.

Such an interface necessarily implies that TLS can't be entirely
transparent to the application, though some aspects of TLS well might
be.

Session resumption and re-negotiation complicate how we identify that
one message, but they hardly make it impossible.  It gets more
complicated if a protocol were to multiplex multiple unrelated TLS
connections on one TCP/SCTP connection/association.   But it's still not
impossible: the application, after all, would be keeping track of the
various streams and keeping them logically separate.

In spite of the _text_ that we need to describe tls-unique being
complicated by session resumption and re-negotiation, the actual
interfaces and source code will be simple.  The complexity is primarily
the result of not having a handy word in the TLS terminology for what
the Microsoft SSPI interface to TLS calls "security context".  If TLS
did define such a term, then it'd be easier to specify tls-unique.

So far I see no real objections to the actual proposal.  Larry objected
that the text might make an implementor think that TLS channel bindings
are associated with TCP connections.  You and Simon would prefer to
speak of the Master secret because that doesn't change when you
re-negotiate -- but that's hardly enough to change gears now, and then
you'd have to bind in things that the Master secret doesn't bind (which
would correspondingly complicate your alternative).

Let's keep things simple.  Please review the proposed text.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Nov 2009 01:01:53 +0100 (MET)

> strike me as a problem -- it's a feature.

You are barking up the wrong tree.

The flaw in Microsoft IIS is, that it's server-side session cache is
somehow broken.  Once it has forced the client through a renegotiate,
it should memorize what the client sent as response to the
CertificateRequest message (either a client cert or the indication
that it doesn't have one or doesn't want to send one).

The way it is currently implemented in IIS, it will force the
client through a renegotiate on every SSL resume.

I never checked how other clients deal with a server that asks
them to do a renegotiate in order to ask for a client certificate.

Since a renegotiate will ALWAYS result in an entirely new TLS session
by performing a full TLS handshake, a sensible client should replace
the previously cached session with the re-negotiated one in the
client-side cache.  A server with a correctly working server-side
session cache will find the reply to the CertificateRequest from
the regenotiation if that session is later resumed on a new
connection and does not need to force a renegotiate when
a client proposes a TLS session resume over a new network
connection (which is what Microsoft IIS currently does).

This strange behaviour of Microsoft IIS only applies for the
renegotiation configuration.  IIRC, when Microsoft IIS is
configured to always ask for the client certificate, it will
do so in the initial TLS handshake and correctly use the memorized
answer of the client on later TLS session resumes.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 3 Nov 2009 17:59:30 -0600

> that it doesn't have one or doesn't want to send one).

Ah, sure, that sounds like a bug.

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Wed, 4 Nov 2009 01:32:26 +0100 (MET)

> is only relevant to writing the text for this channel binding type's

The OooopS refers to the fact, that a TLS session that is renegotiated
results in an entirely different TLS session with an independent
MasterSecret, and I am violently opposed to having to memorize in
the new re-negotiated TLS session anything from a completely unrelated
TLS session.

A full TLS-handshake and a later TLS session are still the same
underlying TLS session, sharing the master secret.  (they do have
connection-specific and direction specific crypto keys, of course).

When a Web Browser loads a new page containing several elements
(style sheets, buttons, icons, frames, etc.), then it first needs
to retrieve the top level document over a single network connection.
Doing so, a new TLS session can be created and added to the
session cache.  The session can be added to the cache as soon
as the TLS handshake is successfully completed, even before
any application data has been transferred.

Having received the top-level document, the browser determines
that it will have to load another dozen or so elements in order
to render the page, and will then usually open several network
connections in parallel (and probably reuse the one it just used
if it is HTTP 1.1 keep-alive).  If session caching on both sides
is working correctly, then the client can resume the original
TLS session on all additional parallel network connections
directly.

If there is one top-level-page, 12 elements and up to 4 parallel
network connections per server, then this will result in
a single full TLS handshake and 3 TLS session resumes and 
one session in the session caches of client and server.

  1st page:  1 full,  3 resumes,  1 session in the server session cache
  2nd page:  4 resumes, 1 session in the server session cache

If your server is a Microsoft IIS with special configuration,
then it goes like this:

1 full TLS-handshake plus 1 renegotiate (=1 full TLS-handshake)
plus 3 TLS-resumes, each followed by a renegotiate (=3 full TLS-handshakes)

  1st page: 5 full, 3 resumes, 5 sessions in the server session cache
  2nd page: 4 full, 4 resumes, 9 session in the server session cache

A full TLS handshake is typically at least 10x more expensive than
a TLS session resume (that is the crypto of the TLS handshake alone,
not counting any fancy certificate path validation or revocation
checking).

> All of that is irrelevant.

No, it isn't.  With channel bindings, you are actually looking/asking for
a particular API semantic.

IMHO, a renegotiation is a problem for both TLS PRF ("extractors")
and channel bindings, because on the wire and at the TLS protocol
level (concerning the TLS session state), renegotiation restarts
everything from scratch.  It does so under protection of a previously
negotiated TLS session, but still, the original and the re-negotiated
session are completely distinct and will void all assumptions that
the application may have associated with the originally established
TLS session.

-Martin

---

From: <[email-masked]>
Date: Wed, 4 Nov 2009 15:13:42 +0100

Martin Rex wrote:

> incarnations (resumes) of the same TLS session.  That is comparable
> to keying to the _most_recent_ finished message -- with __NO__
> special cased for TLS session resume and TLS renogiation.

Note that just extracting some bytes from the TLS master secret (with
TLS extractor) is not sufficient to produce a channel binding,
because with RSA cipher suites, a man-in-the-middle could cause two
TLS sessions to have the same TLS master secret (this is explained in
draft-ietf-tls-extractor-07, Section 5). But those two sessions would
have different Finished messages.

(Version -00 of draft-josefsson-sasl-tls-cb had this problem. Newer
versions avoid it by including the handshake messages (either hashed, 
or via the Finished message) in the calculation.)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 4 Nov 2009 15:28:35 +0100

Nicolas Williams wrote:

>    Description: The client's TLS Finished message (note: the
>    Finished struct) from the first handshake of the connection
>    (note: connection, not session, so that the channel binding is
>    specific to each connection regardless of whether session
>    resumption is used).
> 
> NEW:
> 
>    Description: The client's TLS Finished message (note: the
>    Finished struct) from the first handshake of the application's
>    TLS connection.
> 
>    NOTES:
> 

In any case, I guess we agree that we're referring to the latest TLS
handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)?

Could we somehow refer to this? Perhaps:

  Note: We define a new "TLS connection" to start when the client
  sends an unencrypted (TLS_NULL_WITH_NULL_NULL cipher suite) Client
  Hello message (which can lead to either a full handshake, or
  resuming a session). Renegotiation (sending a Client Hello protected
  under some other cipher suite) does not start a new "TLS connection".  
  Note that this is separate from any notion of "connection", if any, 
  in the underlying transport protocol (such as TCP or UDP).

(Is this consistent with what the existing implementations do?)

Best regards,
Pasi

---

From: <[email-masked]>
Date: Wed, 4 Nov 2009 15:34:38 +0100

Simon Josefsson wrote:

> This reminded me of an earlier observation, and it might be relevant
> to re-iterate it here.  Consider this:
> 
> Day 1:
> 
> 1. Client establish TLS anon-anon to server.
> 2. User authenticates using SCRAM with channel binding to the TLS
>    channel
> 3. User/client disconnects
> 
> Day 2:
> 
> 4. Client resumes the TLS anon-anon connection
> 5. Client rehandshake with X.509 client + server authentication
> 6. User authenticates using SCRAM with channel binding to the
>    TLS channel
> 7. User/client disconnects
> 
> Day 3:
> 
> 7. Client resumes the TLS session
> 8. Client rehandshake it as anon-anon
> 9. User authenticates using SCRAM with channel binding to the
>    TLS channel
> 10. User/client disconnects
> 
> With draft-altman-tls-channel-bindings-07, the channel binding data
> used in all three SCRAM authentications is the same bit sequence.

That certainly was not the intent (the Finished messages used by
SCRAM would be from steps 1, 4, and 7 -- and they're all different).

Can you check if the latest text proposals (Nico's email on 
October 30th, starting "I spoke at length with Larry", and 
my email earlier today) make the situation clearer?

Best regards,
Pasi

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Nov 2009 16:18:44 +0100

> my email earlier today) make the situation clearer?

I have the same question as Martin Rex: what is the actual semantic that
is wanted?  I thought I understood what was intended, but given this
discussion my understanding of what was intended may have been wrong.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 11:46:09 -0600

> handshake sent in clear (with TLS_NULL_WITH_NULL_NULL state)?

Yes (and before any ChangeCipherSpec messages).

>   in the underlying transport protocol (such as TCP or UDP).

I like that.

> (Is this consistent with what the existing implementations do?)

It's consistent with the description that had been registered.  I don't
have an implementation, so I can't say as to existing implementations.
Jeff and/or Larry should know.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 11:55:37 -0600

> SCRAM would be from steps 1, 4, and 7 -- and they're all different).

Indeed, that's absolutely not the intent.  The intent is that you use
the first client Finished message sent on each of those "connections".

Note, incidentally, that Simon's view of how tls-unique was intended to
work, would not be flawed, cryptographically.  It wouldn't interoperate
with other implementations, and it'd be hard to implement (since it
means updating saved session state).  It would conflict the very name of
the channel binding type and it's description as being a "unique"
channel binding type in the RFC5056 sense -- that should be the biggest
clue that Simon's interpretation is incorrect.

I have a very, very hard time understanding how this might not by now be
clear.  It doesn't help that TLS doesn't have a name for the entity from
which we're extracting the channel binding, but that's the only real
problem here.

I also have a very, very hard time understanding how the previous text
could have led anyone to think that TCP connection state should track
TLS channel binding data.  RFC5246 may not have a name for the entity...
but it does speak of "TLS connections", which you can see from the
naming of section 6.1: "Connection States".

Nonetheless I'm happy to revise text to make this matter clearer.  I'd
be happy even to introduce text naming that entity which RFC5246 does
not name.

Nico
--

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 04 Nov 2009 13:14:41 -0500

>> It might be easier to _NOT_ key on the finished message, but on the

Not just too late, but also a bad idea.  Previous discussions relating to 
FAST and anonymous PKINIT resulted in some investigation which, in turn, 
led to the somewhat surprising result that the TLS master secret does _not_ 
name a unique channel, while the finished messages _do_.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 12:12:58 -0600

> discussion my understanding of what was intended may have been wrong.

The desired semantic is that tls-unique channel bindings are a channel
binding in the RFC5056 sense, for a "TLS channel", with this particular
feature (from the I-D):

   o  Channel binding type: unique

(which RFC5056 defines).

Was this not utterly clear already?  How could it not have been?

The only possible point of contention from the above description is just
what a "TLS channel" might be.  And the only reasons for that are:

 - RFC5246 and predecessors don't define a name for what we've been
   calling a "TLS connection";

 - Session resumption might cause someone to be confused and think that
   tls-unique refers to the client's Finished message from the resumed
   session;

 - Re-negotiation might cause someone to be confused and think that
   tls-unique refers to the client's Finished message from the
   re-negotiated "TLS connection".

Let's dispose of these for once and for all:

 - We shall use "TLS connection" to refer to the TLS state created by an
   exchange beginning with a Client Hello message, followed by a TLS
   handshake sequence (which involves a ServerHello, a variety of
   optional messages such as Certificate, and ends in an optional
   ChangeCipherSpec message exchange) followed by an exchange of
   Finished messages.

 - Session resumption establishes new state as per the previous
   definition of "TLS connection", therefore it establishes a new "TLS
   connection", even though session resumption does NOT establish a new
   session.  Therefore, the tls-unique channel binding for a "TLS
   connection" that resumes a session, MUST be the client's Finished
   message from the new connection, not the old session.

 - Re-negotiation consists of initiating a new "TLS connection" while
   using another "TLS connection" record layer for integrity (and
   usually also confidentiality) protection of the re-negotiation.

   As such re-negotiation creates a new "TLS connection".  In this case
   want the tls-unique channel binding to be used by the application to
   be that of the first "TLS connection", that is, the one whose
   ClientHello and handshake were not protected by any other "TLS
   connection".

   (It follows that even if the client does N re-negotiations, where N >
   2, we still want the application to use the tls-unique channel
   binding of the first "TLS connection", the one whose handshake was
   not protected by any other "TLS connection".)

Therefore a "TLS channel" is really: a "TLS connection", as defined
above, whose handshake was not protected by any other "TLS connection".

This is a significantly more rigorous description than the ones we've
discussed so far.  Do you agree that it's air-tight?  Should I propose
new text that adds the above definitions of "TLS connection" and "TLS
channel"?  I think I should, so I will, shortly.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 12:27:04 -0600

On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote:
> I don't pretend to know exactly what this feature is supposed to do,
> but I think using the word "connection" would be a mistake given its
> widespread use meaning TCP connections, etc.

At least the word 'connection' is used in RFC5246 _some_ times to mean
what we were using it to mean here.

> Perhaps using a different word such as "link" would portray the
> meaning you want without causing confusion?

'Link' is even worse.

We'll probably have to include our own definition in the I-D.

The fact that certain words are overloaded does not mean that they
cannot be used.  This is a fact of life in Internet standards, that
terminology varies significantly, and often overlaps, between areas, and
even within areas.  One way to avoid confusion is to indicate, in each
context, the source of one's terminology, and to clarify whenever one
must refer to multiple documents with conflicting terminologies.
Another way is to invent new terminology whenever conflicts arise.  The
latter is very difficult to do and to popularize.  The former requires
discipline.  I prefer the former.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 04 Nov 2009 14:00:20 -0500

>>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:

    Nicolas> On Wed, Nov 04, 2009 at 10:24:29AM -0800, Michael D'Errico wrote:
    >> I don't pretend to know exactly what this feature is supposed
    >> to do, but I think using the word "connection" would be a
    >> mistake given its widespread use meaning TCP connections, etc.

    Nicolas> At least the word 'connection' is used in RFC5246 _some_
    Nicolas> times to mean what we were using it to mean here.

Sanity check here: For the most part, there is a one-to-one mapping
between what we're talking about and TCP connections, right?  In
particular, for most applications, even applications with multiple
finish messages, grabbing the first finish message from a TCP
connection gives exactly the one we want.  Am I correctly
understanding our goal?

If so, this sounds fairly pedantic.  Pedantic is not bad--we should
get it to be correct.  However for most app developers, it seems that
if they assume connection means tcp connection, the right thing will
happen.  If that's not true, then we have a lot of explaining to do,
because if I'm confused, then this is a hard problem to explain.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 04 Nov 2009 10:24:29 -0800

Mike

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 13:05:27 -0600

> between what we're talking about and TCP connections, right?  In

For the most part, yes.

> connection gives exactly the one we want.  Am I correctly

Yes.

> because if I'm confused, then this is a hard problem to explain.

You're not confused.  I fully agree that we've gotten pedantic here.
I don't really understand how anyone could have thought that the channel
binding needed to be communicated to TCP, and thence to the application,
but that's how we got to this point.  Now that we're here, I think we
might as well consider whether we want to have extra rigorous text, or
whether we approve the document as is.

Nico
--

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 04 Nov 2009 20:26:30 +0100

> channel"?  I think I should, so I will, shortly.

With that definition, one couldn't use tls-unique channel binding to
bind to the authentication credentials associated with a TLS channel
uniquely -- a TLS re-negotiation doesn't change the channel binding
data, but it may change the authentication credentials.

I believe that problem needs to be explained in the security
consideration -- it would be easy to think that channel binding data can
be used to get a cryptographic association with the user credentials
used for that channel.

Otherwise I don't see any problem with this definition.

/Simon

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 13:52:08 -0600

On Wed, Nov 04, 2009 at 08:26:30PM +0100, Simon Josefsson wrote:
> > [...]
              ^^^^^^^^^^^^^^^^^^^^^^^^^^
> data, but it may change the authentication credentials.

The point of channel binding is NOT to bind the authentication
credentials of the channel's end-points.  In fact, the point of channel
binding is to allow authentication to happen at a layer above the
channel, so that the authentication, or lack thereof in that channel,
becomes irrelevant.

Please see RFC5056.

> be used to get a cryptographic association with the user credentials

There is no problem.

> Otherwise I don't see any problem with this definition.

Thanks.

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Wed, 4 Nov 2009 22:13:46 +0000

The proposed looks fine. Thanks,

--Larry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Friday, October 30, 2009 3:37 PM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [TLS] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))

I spoke at length with Larry.

His concern is that the word "conenction" might be taken to mean "TCP
connection" or "connection for the transport below TLS".

Clearly it is not reasonable to expect to extract the TLS channel
binding from the "connection for the transport below TLS"!

Larry's proposal to say "session" was only to make that confusion go
away, but that proposal is very difficult to implement (as I described
separately already).

Larry has indicated to me (and I expect will indicate on the list in
reply to this email) that he will be happy if we simply clarify that
"TLS connection" refers to the TLS state, NOT to the transport below.

Unfortunately RFC5246 does not seem to have a term by which to refer the
"TLS connection" unambiguously: "connection" is defined in the glossary
(page 80) to mean that which Larry doesn't want (underlying transport),
but then, in section 6.1 RFC5246 quite clearly uses the word
"connection" to refer to "TLS connection", not to the underlying
transport.

Thus this is a simple matter of wordsmithing.

OLD:

NEW:

   NOTES:

Larry, please review.

Martin, please review.

Nico
-- 
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 16:47:42 -0600

Thanks.

HOWEVER, Martin's post to the TLS WG list about MITM attacks in
re-negotiations is relevant.

Re-negotiations have no real binding between inner and outer
connections.  Clients can enforce that the server end-point is the same
(has the same certificate, whatever) for both connections: inner and
outer.  Servers can also force the inner connection to change cipher
specs.  But suppose that the outer connection used an TLS_DH_anon_*
cipher suite!  Then there is no binding whatsoever between the inner and
outer connection.  And then we have a real problem for tls-unique.

We need at least a security considerations note about this.  But we
should also consider changing tls-unique to be the client's Finished
message for the _inner-most_ TLS connection, not outer-most.
(Outer-most is OK IFF there's a binding between each channel.)

Comments?

Nico
--

---

From: Larry Zhu <[email-masked]>
Date: Thu, 5 Nov 2009 00:03:41 +0000

I think this is good as is. The mentioned issue is in the TLS itself at which layer it knows every well what a TLS connection is so we do not have any confusions related to I mentioned.

Now some comments on the alternative proposals, I would prefer a stable identifier for the channel. If the name of the channel constantly changes when TLS renegotiates, it is a bad taste in the mouth for me.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Wednesday, November 04, 2009 2:48 PM
To: Larry Zhu
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [TLS] New Problem (Was: Last Call: draft-altman-tls-channel-bindings)

Thanks.

Comments?

Nico

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 4 Nov 2009 18:14:47 -0600

On Thu, Nov 05, 2009 at 12:03:41AM +0000, Larry Zhu wrote:
> I think this is good as is. The mentioned issue is in the TLS itself
> at which layer it knows every well what a TLS connection is so we do
> not have any confusions related to I mentioned.

I'm inclined to agree.  In fact, changing tls-unique would have zero
effect in an HTTPS context if authentication would likely be happening
before the server requests a re-negotiation, and if it happens after
re-negotiation then it's too late no matter what.

Therefore I see that we don't need to change tls-unique at all.

> Now some comments on the alternative proposals, I would prefer a
> stable identifier for the channel. If the name of the channel
> constantly changes when TLS renegotiates, it is a bad taste in the
> mouth for me.

tls-server-end-point channel bindings are that.  tls-unique is a unique
type of CB, which means it must be different every time.

We can't have any sort of non-unique channel binding for anonymous-
anonymous channels.  We can have them for anonymous-pseudonymous
channels, but we can't create those from where we stand.

Nico
--