Just because there’s a potential workaround doesn’t mean this is a good idea, especially when you can easily avoid the need for workarounds in the first place. :)
— Justin > On Jan 21, 2016, at 2:15 PM, John Bradley <ve7...@ve7jtb.com> wrote: > > The server could hash the state using the same algorithm the client uses if > the client passed that as well. > > I see lots of things being fragile about that. > > The draft allows the server to use whatever hash it wants to internally to > compare them. Given that we are detecting tamping and don’t need to worry > about collisions as the state should have it’s own integrity protection you > could probably get away with MD5 on the server. Though I don’t think saying > that in a spec would be a good idea:) > > I am being sensitive, because I am changing a decision that was agreed to by > the group in Germany. I want people to know it was changed, so they can > provide feedback if they feel strongly. > > John B. > >> On Jan 21, 2016, at 3:58 PM, Justin Richer <jric...@mit.edu >> <mailto:jric...@mit.edu>> wrote: >> >> Thank you for removing state hashing and please don’t add it back. It’s >> security theater, and that’s giving it the benefit of the doubt. Remember, >> this is being sent in a request where other parameters (code, client_id, >> client_secret, redirect_uri) are all sent plain over TLS as well. Either >> come up with a general mechanism to hash everything or don’t hash anything. >> The latter is more likely to win, and it’s the only thing that makes sense >> currently. >> >> Also, keep in mind that if the client hashes the state on the second >> request, then the server can’t store the state parameter using its own hash >> methods (for data-at-rest protection) and still be able to do the >> comparison. Having the client send it over plain is really better all around >> in terms of simplicity and adoptability. >> >> Now if we really wanted to have message-level protection of HTTP requests, I >> can think of a good way to do that… >> >> — Justin >> >> >>> On Jan 21, 2016, at 9:41 AM, John Bradley <ve7...@ve7jtb.com >>> <mailto:ve7...@ve7jtb.com>> wrote: >>> >>> We merged the state verification in with this rather than forcing people to >>> also look at the JWT encoded State draft. >>> https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state >>> <https://tools.ietf.org/html/draft-bradley-oauth-jwt-encoded-state>. >>> >>> While JWT encoded state is how I would do state in a client and at-least >>> one client I know of uses it, it is not the only way to manage state, and I >>> am hesitant that developers might be scared away by thinking they need to >>> encode state as a JWT. >>> >>> I decided that cross referencing them is better. This made sending much >>> simpler to describe. >>> >>> I also removed the hashing from state. That cut the text by about 2/3 by >>> not having to describe character set normalization so that both the client >>> and the AS could calculate the same hash. >>> That also achieved the goal of not requiring a simple OAuth client doing >>> the code flow to add a crypto library to support SHA256. >>> >>> Once we make a algorithm mandatory, we need to defend why we don’t have >>> crypto agility eg support for SHA3 etc. We would be forced by the IESG to >>> add another parameter to the request to specify the hash alg if we went >>> that direction. >>> >>> Given that we assume state to be public info in the request that an >>> attacker can see, hashing state provides not much value for a lot of >>> complexity that people may get wrong or not implement. >>> >>> I appreciate why from a theory point of view hashing it would have been >>> better. >>> >>> If people really want it I can add it back. >>> >>> John B. >>> >>>> On Jan 21, 2016, at 3:28 AM, Mike Jones <michael.jo...@microsoft.com >>>> <mailto:michael.jo...@microsoft.com>> wrote: >>>> >>>> John Bradley and I collaborated to create the second OAuth 2.0 Mix-Up >>>> Mitigation draft. Changes were: >>>> · Simplified by no longer specifying the signed JWT method for >>>> returning the mitigation information. >>>> · Simplified by no longer depending upon publication of a discovery >>>> metadata document. >>>> · Added the “state” token request parameter. >>>> · Added examples. >>>> · Added John Bradley as an editor. >>>> >>>> The specification is available at: >>>> · http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01 >>>> <http://tools.ietf.org/html/draft-jones-oauth-mix-up-mitigation-01> >>>> >>>> An HTML-formatted version is also available at: >>>> · >>>> http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html >>>> <http://self-issued.info/docs/draft-jones-oauth-mix-up-mitigation-01.html> >>>> >>>> -- Mike >>>> >>>> P.S. This note was also posted at http://self-issued.info/?p=1526 >>>> <http://self-issued.info/?p=1526> and as @selfissued >>>> <https://twitter.com/selfissued>. >>>> >>>> _______________________________________________ >>>> OAuth mailing list >>>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/oauth >>>> <https://www.ietf.org/mailman/listinfo/oauth> >>> _______________________________________________ >>> OAuth mailing list >>> OAuth@ietf.org <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
