Re: RFC 8252 [Process and reviews]

[Michael Thomas <mike@xxxxxxxx>]

On 7/10/23 10:14 AM, Rob Wilton (rwilton) wrote:

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.

It would be best for the AD's involved to explain this instead of just guessing.

 

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.

I looked back at the voting comments and one security AD had no comments and the other AD only had seeming word smithing comments. At least one of the security AD's voted after Adam Roach's comment so I assume he saw it.

 

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).

It's not clear whether "applications" means web applications which were in common use or native phone apps which were barely a thing in 2009. It seems like by 2012, however native apps were included though. Note also: OAUTH is being used for SSO, not just allowing things to post to your Facebook feed, for example, which was as I understand the main motivation at the time (that is, the A in OAUTH is Authorization, not Authentication). The advent of apps of unknown provenance from app stores being used by unsuspecting users was definitely not much of a thing in 2009. By 2012, they were though. The long and short is a lot of the assumptions on the ground were very different by 2012, and certainly by 2017.

And the OAUTH community was extremely hostile when I brought this up 10 years ago. I have no doubt they will continue to be hostile to this day. But that doesn't mean use in native apps is not dangerous. Considering that it is being increasingly used for SSO, the vulnerability today is much worse than when I brought it up 10 years ago.

But DISCUSS's happen all the time for much less. Why did bringing up something so fundamental not even require the working group to explain itself? That's baffling to me.

 

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.

I don't expect IESG members to be omniscient and there are tons of things that get through that maybe shouldn't. This on the other hand is glaring, and so glaring that two non-security AD's found the same fatal flaw. Did the security AD's even discuss what they said? Did they just ignore it? Did they think the other AD's were wrong? They are all invited to chime in here as they are all still active as far as I know.

 

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.

 

My main interest at this point is how something from the security area got through with such a glaring security flaw. This is not some arcane protocol flaw, it's the entire premise that bad guys should be good which is laughable on the same order as RFC 3514 which at least was a April Fools RFC. Good and neutral guys don't need to be told how to use an external browser because they won't be phishing credentials in the first place. So who exactly is this BCP's audience? This is giving the IETF stamp of approval for users to trust that which they shouldn't trust for high value credentials. That is a huge process and technical failure.

Mike