Hi Nikos, On 12/01/15 09:15, Nikos Mavrogiannopoulos wrote: > On Sun, 2015-01-11 at 00:48 +0000, Stephen Farrell wrote: >> Hi Nikos, >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@xxxxxxxx mailing lists by 2015-01-23. Exceptionally, comments may be >>>> sent to iesg@xxxxxxxx instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> This document defines a Signaling Cipher Suite Value (SCSV) that >>>> prevents protocol downgrade attacks on the Transport Layer Security >>>> (TLS) protocol. It updates RFC 2246, RFC 4346, and RFC 5246. >>> The "TLS Fallback Signaling Cipher Suite" fix cannot be a proposed standard. >>> The mechanism it fixes (the browser's special downgrade of TLS) is not an IETF >>> protocol, nor related to the TLS WG. Making this a proposed standard, would >>> imply that the flawed technique is into standards track. >> I don't believe that that last conclusion follows. AFIAK there is >> nothing to prevent the IETF standardising a fix for someone else's >> or even our own past mistakes(*) even when those mistakes are not >> on the standards track. And if in fact stardardising the "fix" >> improves the Internet, then we should do that as the set of folks >> responsible for this technology. (If doing so has IETF consensus.) > > It's not up to me to say whether there was consensus for this draft or > not. Yep, we'll see when the IETF LC is done. > I voiced my opinion against that draft. Not quite. You said this "cannot be" a PS based on an argument that is independent of the content of the draft. > However, if you think that > this has to be on standards track, please provide at least some > argumentation for it. Sorry, I was only answering your general point above, where you said the IETF couldn't produce a PS to fix a problem with a non-IETF thing - I was addressing the "cannot be a proposed standard" part. I think it clearly can, and given that you're moving the discussion along to the specifics of the draft, I assume you accept that. So now you're being more specific and saying that I need to provide an argument that this "has to be on the standards track." I don't think I actually do need to provide such an argument that there was no other good choice - that the TLS WG chose to process it as a PS is reasonable enough. And are we really going to benefit if we argue about the RFC status here anyway? (Especially when it seems from the text below and the WG list discussion that your main issue is with the approach being taken and not with the RFC meta-data or process followed.) But in any case, this is changing protocol that is specified in PS RFCs so a PS RFC does seem like the only good choice in this case. I think the WG also made that choice because this formally updates a bunch of RFCs and they want implementers of those to pick this up, which is a teeny bit more likely with the updates meta-data in the RFC editor's database. That's explicitly noted in the shepherd's write-up [1] and I assume was made clear on the WG list. As also noted in [1] the volume of mail on this was very high, so I'd have to go look. So having this be a PS that updates a bunch of other PS RFCs is cleaner and I hope avoids a bunch of RFC process wrangling. (It is sadly not uncommon for one or other of us on the IESG to quibble about the utterly boring minutiae of such relationships between RFCs as we process them:-) > As far as I understand, this fix exists because Microsoft, Google and > Mozilla cannot coordinate and drop their insecure negotiation of TLS. I don't see that as a new argument. I think we all agree there is a problem. The TLS WG (after much debate) chose this particular approach. At this point I do not see that opinions as to the ultimate cause of the problem are useful for the IETF LC. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/ > > regards, > Nikos > >