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

Nicolas Williams wrote:
> It does.  However, it does also mean that I had to write a bunch of normative text in draft-altman-... to say that apps must do this.  That strikes me as ugly complexity.
> If you never have re-negotiation happening before authentication then why do we need to worry about this?  -- that's my question.

It is amusing that if you actually suggest that it is more complex to leave the behavior as undefined.

-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Nicolas Williams
Sent: Tuesday, March 23, 2010 1:56 PM
To: Larry Zhu
Cc: Mark Novak; channel-binding@ietf.org; Pasi Eronen; tls@ietf.org; sasl@ietf.org
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

On Tue, Mar 23, 2010 at 08:48:41PM +0000, Larry Zhu wrote:
> 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. 

It does.  However, it does also mean that I had to write a bunch of
normative text in draft-altman-... to say that apps must do this.  That
strikes me as ugly complexity.

If you never have re-negotiation happening before authentication then
why do we need to worry about this?  -- that's my question.

> Shall we proceed with that and capture the discussion in the ID (that
> means another update to the ID).

I wrote -09 so as to capture that discussion.

>                                  Personally I am not aware of any new
> data points that would invalidate the above recommendation.

I'm asking questions about your implementation.  The answers to those
questions might actually bring new data points to light that, while they
wouldn't invalidate our earlier decision, might lead us to re-consider
that decision.

Nico
-- 
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls