Pasi.Eronen@xxxxxxxxx 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf