[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Poll: use of TLS channel bindings in SCRAM




After some additional thought and consideration, I change my preference to:

4a (just change the text to require tls-unique)
5 (adds some words that additional text that channel bind type agility is provided via mechanism name).

I have decided not to support providing any channeling binding "downgrade" protection in the mechanism. This because I believe the mechanism downgrade mechanism is sufficient to protect against attacks I think would be likely, and the suggested approaches not necessarily sufficient to cover attacks that might eventual come. For instance, if we were to not only have a channel binding type negotiation facility (such as what Jeffrey proposed) but a Security Label negotiation facility, and maybe a hash algorithm negotiation facility, or maybe a combined "mechanism property" negotiation facility, I would want that negotiation facility to provide a downgrade protection. Off hand, I cannot think of how to deal with downgrade now without discussing the particulars of the negotiation facility, so I rather defer this (and just hope we have enough extension capability in GS2/ SCRAM) to deal with such).

-- Kurt

On May 28, 2009, at 2:49 PM, Alexey Melnikov wrote:


I've discussed channel bindings with Nico in jabber and we agreed that we need to get WG consensus on how TLS channel bindings should be used with SCRAM. Please provide an orded list of alternatives you find acceptable from the choices listed below. (Please restrict discussions of variants of these choices at the moment. I will do another poll on such choices later, depending on the outcome of this poll. Also, please read notes for the choices before answering). Please answer the poll by the end of June 7th.

1). SCRAM should just use a single allowed TLS channel binding and don't have any negotiation of other TLS channel bindings (*) (**)
a). the default is tls-unique
b). the default is tls-server-end-point
2). SCRAM should just use tls-server-end-point, fallback to tls- unique, no negotiation of other TLS channel bindings (*)
3). SCRAM should always use channel binding negotiation (*)
4). SCRAM should have a default TLS channel binding with optional negotiation of TLS channel bindings (*)
a). the default is tls-unique
b). the default is
5). I have another opinion [this is for the case when there is some valid choice which you think should be considered by the WG]

Notes:
(*) - whether such negotiation happens inside or outside of SCRAM
(**) - channel binding negotiation can be added later on