RE: RFC 8252 [Process and reviews]

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

Hi Mike,

 

Even now, not being an expert on OAUTH or security, I don’t really know whether it was right for RFC 8252 to be published – but I do have sympathy for your concerns.  I can imagine that there was perhaps a discussion in the IESG about how doing it in the browser it better than doing it in the app, and probably an augment that OAUTH is more secure than the apps individually managing passwords.  So, rightly or wrongly, they may have deemed that publishing this to not be perfect, but better than the alternatives.

 

I think that it is also somewhat hard for ADs in other areas to override (i.e., put a blocking DISCUSS) for a security issue on a document coming out of the SEC area.  I.e., it would have been clear that the experts in the area (i.e., the two SEC ADs) were okay with this being published.  I can’t speak for the SEC ADs at the time, but my general experience whilst I have been on the IESG is that the SEC ADs have always been quite strict on what they will (or will not) accept from a security perspective.

 

Further, looking at the charter for the OAUTH WG, since 2009 when the WG was first formed, it has started with the text: 

“The Web Authorization (OAuth) protocol allows a user to grant a

third-party web site or application access to the user's protected

resources, without necessarily revealing their long-term credentials,

or even their identity

”

 

I.e., it seems that it was, and is, very much in the OAUTH WG charter to produce a solution for applications, which again, makes it harder to block a document that looks like it is within the WG charter scope.  One of the many things that I have learned as an AD is that reviewing WG charters very carefully when proposed and when a WG is rechartered is perhaps the most effective way of controlling what work can happen – at a time that folks won’t get upset (or get less upset) than having them waste a lot of time writing a document that is blocked from publication at the last major stage of the process.   Note, I’m not saying that the IESG should never block documents if they are clearly harmful, even if they are in scope of the WG charter, but you have got to be pretty sure, because some part of the community will generally be pretty unhappy with you (e.g., authors, WG).

 

I do want to pick out what I think is perhaps a bigger issue here, is that the IETF relies on documents being published with the consensus of the IETF, but I generally see very few reviews of documents happening during IETF LC, it is generally only the directorate reviews, and sometimes a few others.  Possibly, in hindsight, moving last-call reviews and discussion off the main IETF alias may not have helped (and IIRC, I was complicit in that happening as a new AD).  This ends up leaning more heavily on the WG and IESG to get it right, and for some WGs, it can feel like they are often working in a silo, and generally less happy to receive review feedback after the document has exited WG LC.

 

But IETF does have a process for rectifying problems – i.e., follow the same IETF process as how the original RFC was published.  E.g., write a draft indicating the problems with RFC 8252 and marking that RFC as historic.  But you would still need to achieve rough consensus to publish, which means that you need to convince a significant proportion of the IETF security community that this is the right thing to do.  If you can convince the OAUTH folks then that would probably be the easiest path, but if you can’t then trying to bring it to SAAG or SECDISPATH seems like the alternative path.  But it is still possible, that despite its flaws that RFC 8252 still has IETF consensus as a BCP.

 

Regards,

Rob

 

 

 

From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of Michael Thomas
Sent: 06 July 2023 18:51
To: Abdussalam Baryun <abdussalambaryun@xxxxxxxxx>
Cc: ietf@xxxxxxxx
Subject: Re: RFC 8252

 

 

On 7/6/23 12:53 AM, Abdussalam Baryun wrote:

 

 

On Thu, Jul 6, 2023 at 2:59 AM Michael Thomas <mike@xxxxxxxx> wrote:

On 7/5/23 1:12 PM, Brian E Carpenter wrote:
>
> I do agree that any actual *action* such as a draft replacing RFC8252
> or proposing a new auth mechanism belongs elsewhere.
>
Also: I had no idea what the proper venue was beyond the OAUTH wg which
would be pointless since they were extremely hostile when I first
brought it up and I'm not eager for another beating down. There needs to
be some process recourse when a wg has gone off the rails even if it's
after years after the RFC was issued. I mean, what if this is being
actively exploited in the wild but the wg doesn't want to hear about it?

 

IMHO as understanding IETF procedure, if some one is part of the IETF WG (i.e. WG participant that discusses on WG lists and shows up in meetings), then they must prove that they are with full consensus while WG LC (i.e. the first_community round for consensus). If that round finishes, we should go to the second community_round while IETF LC, so did you continue to comment in IETF LC while the IESG asks the community to feedback? 

 

I had no idea that rfc 8252 was going on. Requiring IETF omniscience is a complete non-starter. Not everybody's day job is to monitor sketchy work coming out of working groups. AD's can barely do that. Barely. The rest of us, not so much.

And if IETF cannot rectify harmful errors after the fact, that is another process failure. Bad guys are thankful if IETF thinks that last call is sacrosanct and the last word. The rest of the world is glad that CVEs exist.

Unless it is the opinion of the IETF that the participants must be full time, this is extremely wrong-headed. The IETF would lose probably 99% of its participants if that were true.

Mike