Re: [kitten] Review of draft-ietf-kitten-channel-bound-flag-04

[Sam Hartman <[e-mail]>]

>>>>> "Greg" == Greg Hudson <[e-mail]> writes:

    Greg> On 2/18/19 4:39 PM, Sam Hartman wrote:
    >> However, I think that the decision as to what to do should be
    >> based on analysis of applications where one side uses channel
    >> bindings and the other does not.  Since I'm not actually aware of
    >> any significant applications that do that, I'll hold off until my
    >> previous question on that issue is answered before forming my
    >> opinion on the correct behavior.

    Greg> I think the practical motivation for this draft is a desire to
    Greg> add channel bindings to application protocols which do not
    Greg> currently use them.  I believe HTTP Negotiate is commonly
    Greg> given as a candidate.  So, while I am not sure there are any
    Greg> applications in this category today, there is a desire to (at
    Greg> least temporarily) create some in the future.

HTTP negotiate seems like it will be an interesting design thought
exercise.

While working on Moonshot we spent some time trying to figure out how we
would approach channel binding for HTTP negotiate.

It seemed like deployment considerations made it kind of tricky.

Do I use unique or endpoint channel bindings?  That depends on several
factors:

* To use unique channel bindings I need to produce the GSS-API token on
  the client after the TLS connection is established.  That assumes a
  certain model for how the HTTP and TLS libraries interact.

* To use unique channel bindings on the server, I need access to  the
  appropriate hashes; that assumes my HTTP library and my TLS library
  make that available to whoever is producing the GSS token.  (In many
  but not all cases that will be part of the HTTP library)

OK, so just use endpoint channel bindings and be done with it.

Does the server actually know its endpoint channel binding?  If it's
behind a reverse proxy, that may depend a lot on the configuration.  TLS
may terminate at the reverse proxy.  The connection behind the reverse
proxy may be unencrypted, or it may be encrypted using a different
certificate.

We don't want to break things that work today.  Yes, channel bindings
would make that situation more secure, but HTTP negotiate has value
without channel bindings, demonstrated by the people who use it today.

Also, we've already found bugs in channel bindings (even for TLS).  So,
we probably want some sort of transition strategy.

So, it seems like you're almost always going to want some application
layer something to figure out whether channel bindings are supported on
both ends and whether to use them.  (And probably if they get used a
lot, which channel binding to use).
That's frustrating because it makes channel bindings not so simple.

Some thoughts:

The Moonshot behavior (null acceptor bindings ignores any initiator
  CB) makes it easier for people to withdraw from the channel binding
  process when  local configuration does not support channel binding.
If it weren't for there being multiple types of channel binding and a
  need to think about transitions, I'd argue that makes the Moonshot
  behavior clearly supperior especially if there are not currently
  applications that don't know whether they are doing CB.

Given that we probably should care about those issues, I'm not at all
sure I know what the right behavior should be for applications that do
not support this flag.

I'm still definitely in favor of the flag.  The more I look at this, I
don't think this is fixing a flaw in GSS-API, and I especially am not
seeing the security flaw.
I think it's adding a new capability with some tricky interoperability
and deployment considerations.