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

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.

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.

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.

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