Re: RFC 8252 [Process and reviews]

[Michael Thomas <mike@xxxxxxxx>]

On 7/12/23 7:25 AM, Rob Wilton (rwilton) wrote:

[Rob Wilton (rwilton)]
Generally, in the current IESG, we do.  Sometimes ADs ballot a “discuss DISCUSS”, i.e., perhaps something that are not an expert on, and hence don’t specifically know that it is wrong, but they want to specifically flag an issue for further discussion – i.e., preventing a document from being approved without some level of discussion having occurred.  Often such discussion happens, concerns are alleviated, and the DISCUSS position is cleared (to Yes or No Objection), and the document progresses.

But my key point is that if the conversation happened, and the security ADs both indicated that they regarded this issue as having been considered (by the WG and themselves), and were happy with the outcome, then I personally wouldn’t feel particularly comfortable continuing to hold a blocking discuss position (to prevent publication of the RFC) for an architecture issue which is really under the jurisdiction of another area.  I.e., even if a discussion had happened, then it is still plausible that the IESG would collectively reach the same outcome, i.e., it is okay for the document to be published.

Sometimes, at least for the current IESG, ADs move to ballot Abstain in this scenario – i.e., they don’t really support the document being published (i.e., they have objections that probably cannot really be addressed by minor changes to the text), but neither will they stand in the way of the document being published.

I will also reiterate a point that I made previously – getting more reviews at IETF LC would be nice, but it is currently hard and those reviews come late in the process causing conflict if they are very significant comments.  Hence, I’m still convinced that it is the BOFs and WG charters that are a more effective way of controlling what a WG is allowed to work on, and to put constraints on what the solution must or must not do.  I.e., if documents reach the IESG that are not in the scope of the WG charter, then it is quite likely that an AD will put a DISCUSS on the document and may delay clearing the DISCUSS until the charter has been updated (allowing an IETF review of the charter changes) to bring the work in scope.  Charters don’t change that frequently, and hence if a participant has  limited time to spend on cross area review, then that may be a good place to focus their time and energy.

Yet here we are in a situation where the entire premise of a BCP in this case is manifestly silly -- that bad guys should be good. I can easily see that getting by a charter which is probably of the form "what should we do about native apps?" where it's open ended as to what the solution is. So I don't fault the process there. What the working group should have said is "don't" except in the narrow more Kerberos like situation where the services are trusted (and frankly begs the question of why not use Kerberos in the first place). But for whatever reason in the face of a new reality of untrusted apps in a sea of them in app stores they decided publish a misguided BCP anyway premised on bad guys being good.

So it begs the question of what the IESG should do with something so fatally flawed. Two AD's found the same problem. At the very least their concern should have been put into the document in blinking bold yet it wasn't. But really what should have happened is for the entire document to be junked. There really was nothing to be reworked because the entire base assumption was flawed. What is the proper process for that? And what of the security AD's who were apparently at the very least indifferent to the problem? Do they actually think that asking bad guys to be good is a valid security strategy? 

This is why I'm so concerned about why this happened and how to prevent something like this happening in the future. That's especially true when it involves security risks at a very large scale.

Mike