I tend to agree with Torsten here - similar sentiments were (maybe not well) expressed a few weeks ago: http://www.ietf.org/mail-archive/web/oauth/current/msg14155.html
On Wed, Feb 18, 2015 at 6:36 AM, <tors...@lodderstedt.net> wrote: > Hi Nat, > > as far as I understand, the length of at least 32 octets is justified for > S256 only. So limiting the MUST to S256 would be ok (from my perspective). > I consider a general MUST (which also applies to plain) a to strong > requirement. > > kind regards, > Torsten. > > Am 18.02.2015 10:50, schrieb Nat Sakimura: > > Is there anyone who has problems changing it to a MUST? > On 2015年2月18日(水) at 18:48 Hannes Tschofenig <hannes.tschofe...@gmx.net> > wrote: > >> I think that the "controlled environment" is a risky idea. I believe we >> should definitely go for a MUST. >> >> On 02/18/2015 10:26 AM, Nat Sakimura wrote: >> > Hi Hannes, >> > >> > The reason I have put SHOULD there instead of MUST is >> > that there may be a valid reason not to in a controlled >> > environment, and it does not interfere the interoperability. >> > The deployment may opt to use other control than entropy, >> > and SHOULD allows it while MUST does not. >> > >> > Having said that, if the WG is OK with a MUST there, >> > I am fine with incorporating the proposed change. >> > >> > Cheers, >> > >> > Nat >> > >> > >> > On Wed, 18 Feb 2015 09:43:30 +0100 >> > Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: >> > >> >> Hi Nat, >> >> >> >> thanks for the quick response. >> >> >> >> I was hoping to see a statement like "The code verifier MUST have >> >> enough entropy to make it impractical to guess the value." in the >> >> text rather than the SHOULD. Given all the other statements in the >> >> draft I am not sure what the should actually means. Under what >> >> conditions would an implementer not provide enough entropy to make >> >> guessing impractical? >> >> >> >> Ciao >> >> Hannes >> >> >> >> On 02/18/2015 05:13 AM, Nat Sakimura wrote: >> >>> Hi Hannes, >> >>> >> >>> I hereby confirm that I have submit the draft in full conformance >> >>> with the provisions of BCP 78 and BCP 79. >> >>> >> >>> Re: Security Consideration (7.1) and section 4.1 >> >>> >> >>> The first part of the 7.1 is a non-normative prose explaining that >> >>> the implementers got to make sure that the code verifier is hard to >> >>> guessed or modeled. In a way, this is laying out the basic security >> >>> property requirment on the code verifier. >> >>> >> >>> Then, it goes onto the implementation guideance that one need to >> >>> use a cryptographic random number generator instead of relying on a >> >>> rand() in some language that are not cryptographically random to >> >>> generate 32-octet sequence. The same text is in 4.1 as well. >> >>> >> >>> We did not copy "code verifier SHOULD have enough entropy to make >> >>> it impractical to guess the value" here because that looked >> >>> needlessly repeating, but if you want, I have no objection in >> >>> adding it to 7.1. >> >>> >> >>> Alternatively, in 7.1, after explaining the rationale, we can just >> >>> point to 4.1 for the control and implementation guidance. >> >>> >> >>> Re: 32-octet >> >>> >> >>> We chose it because we are using SHA256 in generating the code >> >>> challange. Having more entropy does not help us here, while having >> >>> less octets increases the risk. >> >>> >> >>> Best, >> >>> >> >>> Nat >> >>> >> >>> >> >>> >> >>> On Tue, 17 Feb 2015 17:56:33 +0100 >> >>> Hannes Tschofenig <hannes.tschofe...@gmx.net> wrote: >> >>> >> >>>> Hi Nat, John, Naveen, >> >>>> >> >>>> thanks a lot for your work on the document. >> >>>> >> >>>> I still need responses to this mail to complete the shepherd >> >>>> writeup: >> >>>> http://www.ietf.org/mail-archive/web/oauth/current/msg14100.html >> >>>> >> >>>> I definitely need the IPR confirmation. >> >>>> >> >>>> It would also be helpful to have someone who implemented the >> >>>> specification as it currently is. I asked Brian and Thorsten for >> >>>> clarification regarding their statements that they implemented >> >>>> earlier versions of the spec. >> >>>> >> >>>> As a final remark I still believe that the text regarding the >> >>>> randomness is still a bit inconsistent. Here are two examples: >> >>>> >> >>>> 1) In the Security Consideration you write that "The security model >> >>>> relies on the fact that the code verifier is not learned or >> >>>> guessed by the attacker. It is vitally important to adhere to >> >>>> this principle. " >> >>>> >> >>>> 2) In Section 4.1 you, however, write: "NOTE: code verifier SHOULD >> >>>> have enough entropy to make it impractical to guess the value. It >> >>>> is RECOMMENDED that the output of a suitable random number >> >>>> generator be used to create a 32-octet sequence." >> >>>> >> >>>> There is clearly a long way from a SHOULD have enough entropy to >> >>>> the text in the security consideration section where you ask for >> >>>> 32 bytes entropy. >> >>>> >> >>>> It is also not clear why you ask for 32 bytes of entropy in >> >>>> particular. >> >>>> >> >>>> Ciao >> >>>> Hannes >> >>>> >> >>> >> >>> >> >> >> > >> > >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
