Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

[Larry Zhu <[e-mail]>]

I briefly chatted with Sam who was in the tls-unique design/discussion meeting last Sunday. It turns out that the community as represented by key stake holders in that meeting believed that:

1) TLS renegotiation is driven by TLS apps.
2) as the result, the apps can figure out, based on the app specific context, which TLS side will start renegotiation and when, e.g. in a locked-step fashion.
2) therefore it is acceptable to leave the behavior in the case of the described synchronization undefined.

If this does not capture the spirit of that discussion, please let me know. 

Shall we proceed with that and capture the discussion in the ID (that means another update to the ID). Personally I am not aware of any new data points that would invalidate the above recommendation.

Thanks,

--Larry


-----Original Message-----
From: Nicolas Williams [mailto:[e-mail]] 
Sent: Tuesday, March 23, 2010 1:00 PM
To: Larry Zhu
Cc: [e-mail]; [e-mail]; [e-mail]; Mark Novak; Pasi Eronen
Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

On Tue, Mar 23, 2010 at 07:56:19PM +0000, Larry Zhu wrote:
> > It occurs to me that it must be very unlikely that any apps using the
> > MSFT variant of tls-unique are doing authentication after TLS
> > re-negotiation.
> 
> Should we instead say that the receiver/verifier of the tls-unique
> binding is encouraged to remember the previous finished structure
> before re-negotiation. If the synchronization is more than 2 finished
> messages apart, the auth request is expected to fail.

What's the motivation?  Is it really that hard to keep the initial CB
around?  It is tiny...

> This way we have a solution when the actual need arises, without
> complicating either the interface or the protocol. Hopefully the
> burden to implementation is minimal as well. Is that reasonable?

Ah, I think I understand.  In your API it's the application's burden to
remember the CB from the initial handshake.  But even so, that does not
seem like such a tough burden.

Your proposal is more reasonable than the earlier one for the simple
reason that we'll never see three handshakes prior to authentication,
and accepting the possibility of spurious authentication failures in
such cases, if they happened, would be OK with me.

Nico
--