Re: [OAUTH-WG] draft-ietf-oauth-spop-10

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, <torsten@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.tschofenig@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.tschofenig@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.tschofenig@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
>
>