Re: [E] Re: HTTP State Tokens

The primary use case is a token theft and replay attack. Being able to bind
a cookie to the browser instance to which it was issued prevents the replay
possibility outside of that specific browser instance. I realize the old
token-binding spec solved this problem and the general response to that is
that HTTPOnly with TLS mitigates the attack. However, there are other ways
in which tokens can be compromised (e.g. server side exposure) and being
able to bind the token to the browser instance mitigates such exposures and
subsequent replay mechanisms. Most of the use cases I'm focused on are
Identity related use cases and I'm always looking for ways to better
protect authentication/session/authorization credentials.

Also happy to explore other ways to protect these Identity elements :)

On Tue, Apr 13, 2021 at 9:08 PM Kaustubha Govind <kaustubhag@google.com>
wrote:

>
>
> On Thu, Apr 8, 2021, 10:14 AM George Fletcher <
> george.fletcher@verizonmedia.com> wrote:
>
>> Hi Mike,
>>
>> Thanks so much for the response! I found the ability for the user agent
>> to generate a signature for the state tokens very intriguing. Is there any
>> chance we could add that feature to existing cookies via some mechanism?
>> Maybe an attribute for a "set-cookie" response header?
>>
>> Thoughts?
>>
>
> George: I'm curious to hear about the threat model you're trying to solve
> for. Mike's proposal speculates that the signing key could potentially help
> mitigate attacks possible via token theft, but leaves open the possibility
> that the design could be improved upon.
>
>
>
>> Thanks,
>> George
>>
>> On Thu, Apr 8, 2021 at 1:18 AM Mike West <mkwst@google.com> wrote:
>>
>>> Hey George,
>>>
>>> There was discussion on the IETF's HTTP working group list, and in
>>> WebAppSec. My impression from those conversations was that there wasn't
>>> enough appetite for building a cookie replacement vs. incrementally
>>> changing cookies as they exist. That's the strategy laid out in
>>> https://mikewest.github.io/cookie-incrementalism/draft-west-cookie-incrementalism.html
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mikewest.github.io_cookie-2Dincrementalism_draft-2Dwest-2Dcookie-2Dincrementalism.html&d=DwMFaQ&c=sWW_bEwW_mLyN3Kx2v57Q8e-CRbmiT9yOhqES_g_wVY&r=cl87BDJWy_Dken1-bgbUZHoY1dEfYnAZIzXekbjJhbc&m=PF75H_jMRGPCLyMfWDj-A4dzaaPqTcbqyYtjw89EGLo&s=F7i2jxquOErF2Ge7jHxCrCcLy3KYBsaY2LFPcDC8dps&e=>
>>> .
>>>
>>> From my perspective, state tokens are on hold while vendors determine
>>> just how malleable existing cookies actually are. I'd love to see folks
>>> collectively decide to pick them up again as I think there's some value in
>>> shipping a modernized version of that draft, but I'm happy to see the
>>> energy flow into incremental change for the time being. :)
>>>
>>> -mike
>>>
>>>
>>> On Wed, Apr 7, 2021 at 9:42 PM George Fletcher <
>>> george.fletcher@verizonmedia.com> wrote:
>>>
>>>> Thanks! I remember it being discussed but then it seems like discussion
>>>> has gone silent. The IETF draft expired in September 2019 :)
>>>>
>>>> On Wed, Apr 7, 2021 at 3:38 PM Kaustubha Govind <kaustubhag@google.com>
>>>> wrote:
>>>>
>>>>> Adding +Mike West <mkwst@google.com> (author of the proposal).
>>>>>
>>>>> It was discussed on the WebAppSec WG mailing list months ago.
>>>>>
>>>>> On Wed, Apr 7, 2021 at 3:15 PM George Fletcher <
>>>>> george.fletcher@verizonmedia.com> wrote:
>>>>>
>>>>>> This may not be the correct venue but figured I'd ask to see if
>>>>>> anyone knows the status of HTTP State tokens.
>>>>>>
>>>>>> Thanks,
>>>>>> George
>>>>>>
>>>>>>
>>>>
>>>>
>>