FYI, at the very beginning of the work, we suggested developers to go with
at least S256, but the response we got was flatly "NOT". As John has
written, "plain" mitigates the attack they are facing and there was no
appetite to go any further... It is a bit unfortunate, but we would have to
face the reality and make the life better a step at a time. It certainly is
better to have them doing it in a standardized way than have them in the
proprietary silos.
Nat
-----Original Message-----
From: John Bradley
Sent: Tuesday, June 09, 2015 11:04 PM
To: Barry Leiba
Cc: Alexey Melnikov ; IETF Gen-ART ; [email protected] ;
The IESG
Subject: Re: Gen-ART Review of draft-ietf-oauth-spop-11
Keeping the plain for clients option was part of getting some of the larger
players like Google, and DT to implement it.
For known attacks plain is fine.
As a datapoint I had one of the Azure people tall me last night that they
get push back by developers on doing the base64url
encoding. Nothing surprises me about developers.
There are some extensions to other specs that may use PKCE where S256 would
be required,
so having it as MTI on the server is a good thing.
John B.
On Jun 9, 2015, at 6:11 AM, Barry Leiba <[email protected]> wrote:
In the majority of situations (the ones currently exploited) on iOS the
attacker only has access to the response coming back from the
AS and not the request with the code_challenge. This is to do with
the way custom scheme redirects work in the OS.
Ack; thanks for that explanation.
The feedback was that there are some developers that would rather
ignore the risk than do S256.
I find that curious, as it's very little code involved.
I'm still not certain that we should publish a standard protocol that
allows this weakness, rather than requiring that it be robust.
But I'll let my Sec AD colleagues weigh in, and will go with their
opinions on it.
Barry
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
