RE: RFC 8252 [Process and reviews]

["Rob Wilton \(rwilton\)" <rwilton=40cisco.com@xxxxxxxxxxxxxx>]

 

 

From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Michael Thomas
Sent: 12 July 2023 19:04
To: ietf@xxxxxxxx
Subject: Re: RFC 8252 [Process and reviews]

 

 

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.

[Rob Wilton (rwilton)]

I’ve tried to explain the aspects of the IESG approval process that I can, but I wasn’t on the IESG at the time that this document was approved, so if you want more information beyond what is in the minutes, then I think that you will need to directly email the SEC ADs who were in post at the time.

But I think that we need to be careful about changing (in particular adding) new process to the IETF publication pipeline.  I think that I’ve seen various cases, where some flaw with the processing of an RFC happened in the past, and hence someone goes to the effort of updating the process, nominally to ensure that a similar mistake can never happen again.  What sometimes happens is that new step or rule in the process has unexpected and unintended side-effects that causes extra process hoops to be jumped through for no real benefit. I.e., the negatives of the extra step greatly outweigh the benefits that it brings in a small number of cases.

Instead, I think that it is more pragmatic to try and ensure that the IETF publication process is light enough and works well for 95+% of documents, and to handle the odd exceptional case as an exception, and also accept that occasionally the IETF will end up publishing documents that in hindsight have flaws or would have been better not to publish, and that is okay, since we can always publish a new RFC to undo the mistake.  I don’t know whether RFC 8252 fits into the category or not, but I agree with Chris that discussing that aspect on this list is unlikely to be constructive or useful.  To get anything to change needs the discussion to happen within the security area lists, probably by bringing a draft, as explained previously.

Regards,
Rob

 

Mike