Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [TLS] [CHANNEL-BINDING] RESOLVED (Re: [sasl] lasgt call comments (st Call: draft-altman-tls-channel-bindings (Channel Bindings for TLS) to Proposed Standard))



On Wed, Nov 04, 2009 at 02:00:20PM -0500, Sam Hartman wrote:
> >>>>> "Nicolas" == Nicolas Williams <Nicolas.Williams at sun.com> 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

For the most part, yes.

> 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?

Yes.

> 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.

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
-- 

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.