Pasi(_dot_)Eronen(_at_)nokia(_dot_)com wrote:
- Whether to prohibit sending the extension (in initial ClientHello),
or require the magic cipher suite even if the extension is sent (in
initial ClientHello): The consensus is again a bit rougher than we'd
normally hope to see, but the current text (either is allowed) has
more support (about 2/3 vs. 1/3), so we keep it. And again, I believe
most participants prefer make some decision over continuing the
discussion.
I'm sorry for creating a confusion and dispute about this.
Allowing the sending of an empty extension RI on initial ClientHello
should not be a problem and I would find a MAY perfectly acceptable.
The real important thing is, that the inclusion of the MCSV is
a MUST, because it will reduce the procotol complexity and robustness
and allow absolutely _every_ implementer to save code.
- There was some discussion on whether to add the magic cipher suite
to patched renegotiation ClientHellos (in addition to the extension),
too. I believe rough consensus is not to do this.
I have a VERY strong objection to leave out the MCSV from any
ClientHellos. It will save everyone code if we mandate the
use of MCSV on all ClientHellos including secure renegotiation
ClientHellos, and it will make the protocol *MUCH* more foolproof.
- The current draft doesn't clearly say what should be included in
legacy (insecure) renegotiation ClientHellos. I am not sure if we have
enough clear opinions to call consensus, but keeping it aligned with
the initial ClientHello (either MSCV or extension) seems to be one
simple approach (but I hope to see the actual text).
Again, the choice is obvious: MCSV, *NO* extension.
Anything else just makes no sense and may obviously cause interop
problems for some backwards interop scenarios, because it is
a backwards-incompatible change.
About the backwards interop scenarios in general:
Can we please discontine the misleading terminology "lenient client/server"
and instead refer to the specific backwards interop scenarios that
we address with a recommendation?
(1) updated client allowing initial handshakes with old servers
(2) updated client allowing renegotiation handshakes with old servers
(3) updated server allowing initial handshakes with old clients
(4) updated server allowing renegotiation handshakes with old clients
As i previously mentioned, I think that we want to get rid of
(4) as fast as we can (SHOULD NOT), hope to get rid of (2)
at the end of the transition period (MAY), and leave (1) and (3)
completely to the consumers of the technology.
I'm strongly opposed to any suggestions to impair (1) or (3) in
the solution we ship.
I realize that not everyone will be happy with these decisions, but in
my judgment as Security Area Director, the choices are in line with
the rough community opinion, and are technically reasonable (many
other choices would have been reasonable, too). In particular, I
believe that continuing these discussions until some indeterminate
time in 2010 would not be in the best interest of the community (many
of whom have expressed that they prefer an OK solution this year,
instead of possibly-slightly-improved one next year).
I do not agree to your determination of rough consensus.
rfc4677, 5.2 Getting Things Done in a Working Group
Another aspect of Working Groups that confounds many people is the
fact that there is no formal voting. The general rule on disputed
topics is that the Working Group has to come to "rough consensus",
meaning that a very large majority of those who care must agree.
The lack of formal voting has caused some very long delays for some
proposals, but most IETF participants who have witnessed rough
consensus after acrimonious debates feel that the delays often result
in better protocols. (And, if you think about it, how could you have
"voting" in a group that anyone can join, and when it's impossible to
count the participants?) Rough consensus has been defined in many
ways; a simple version is that it means that strongly held objections
must be debated until most people are satisfied that these objections
are wrong.
It just doesn't feel right if some peoples feelings about aesthetics
are considered more important than other peoples technical issues.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf