Re: [CHANNEL-BINDING] Re: draft-ietf-sasl-gs2 AD review comments

On Wed, Oct 10, 2007 at 11:16:00AM -0400, Jeffrey Hutzelman wrote:
> On Wed, 10 Oct 2007, Nicolas Williams wrote:
> 
> > The more I think about the who's-responsible-for-prefixing issue the
> > more I realize that the I-D shouldn't speak to that issue.  I could see
> > an operating system where all channels report channel bindings with the
> > prefix already included, another where only some do, and another where
> > none do -- but in all cases the applications can deal and interop
> > provided that the applications know which channels include the prefix
> > when and which don't.
> 
> Again, I don't care what the operating system or the library does.  Of
> course the document should not speak to that; focusing on API issues
> rather than protocol issues misses the point, which is that independent
> implementations be able to interoperate.

Part of the point of the e-mail to which you're replying was to take the
focus off APIs.

> What I _do_ care about is that it's clear in every case what the bits are
> supposed to look like on the wire and what the application protocol
> specification is responsible for doing.  If the application protocol is
> supposed to provide a single slot which will contain the prefix followed
> by the channel binding data, then say so, and specify exactly how they are
> combined.  If the application protocol is responsible for separately
> transporting the prefix and channel binding data, then say _that_, and
> make it clear that you need integrity protection for both.

Please re-read the bits you didn't quote.  I believe there's a guarantee
of non-ambiguity.

> Otherwise you're going to get into a situation where the base document
> expects the app to transport the two elements separately, but the author
> of an application protocol thinks he only gets one blob which contains
> both, and then you have a mess because implementors don't know what to do
> with the prefix (ignore it?  prepend it to the data?  how?) and either
> nothing interoperates or you end up with an application protocol that you
> can't implement correctly without making undocumented assumptions.
> 
> 
> 
> 
> 
> BTW, an environment in which some channels report data without a prefix,
> others report it with the prefix followed by ':', and still others report
> it with the prefix followed by NUL is about the worst thing I can think
> of.  Anyone actually designing an API for this should define a consistent
> way of doing it.

I wrote nothing about the separator being variable or the prefix being
optional.  The text about operating systems was to illustrate that we
need not say who is responsible, API-wise, for adding the prefix, as
long as it is added.  Please re-read carefully.

Nico
-- 

_______________________________________________
CHANNEL-BINDING mailing list
CHANNEL-BINDING@ietf.org
https://www1.ietf.org/mailman/listinfo/channel-binding