IETF Logo Mail Archive

Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?

Daniel Fett <fett@danielfett.de> Sun, 05 November 2023 19:14 UTC

Return-Path: <fett@danielfett.de>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14DDC17C88D for <oauth@ietfa.amsl.com>; Sun, 5 Nov 2023 11:14:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=danielfett.de
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KZAXyiIFDCj for <oauth@ietfa.amsl.com>; Sun, 5 Nov 2023 11:14:12 -0800 (PST)
Received: from mout-p-102.mailbox.org (mout-p-102.mailbox.org [80.241.56.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD02BC31A60C for <oauth@ietf.org>; Sun, 5 Nov 2023 11:08:42 -0800 (PST)
Received: from smtp202.mailbox.org (smtp202.mailbox.org [IPv6:2001:67c:2050:b231:465::202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-102.mailbox.org (Postfix) with ESMTPS id 4SNkXk1Yb6z9scm for <oauth@ietf.org>; Sun, 5 Nov 2023 20:08:38 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=danielfett.de; s=MBO0001; t=1699211318; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=FUv88jSmdkdyRBJ7PHMqTtQTe4V4vqGakxdmXMshgnY=; b=F5l10D5Z1vrqc3iVNGgUCYKXOLOy/IAZGd1vRlZUwVtfMXJ5IV9KKmNgeYspfgdaX0wfzA 9+gopKDMA5HfK1RTqqTRC//mK25je2mPO+XPli7bRLYOBWozQ+ODjnlYKg35pRatNgh4SH Ym1cSRWxfCC4twYMZ8eaIy6JEpJiF5i6ORPESVVkQFG/4pBZQ27AN01YQckZpG9fsjVOCK DJrHoYSyQtEhnH5aplvN2YC6PWOW7bBsUQpZs5mqHMMQLgswC2uYqbJnKfIOIFT8L9jwNY eS7mVdydtJpA5cAVK0I1hUfo8/bIIxP5qHmRF1IEvGfFWI485/Dxk90mVti/8g==
Content-Type: multipart/alternative; boundary="------------mtNQK120twT51a1DQfo1KRiY"
Message-ID: <f6383d62-9586-49c9-a824-9d92288ee4bd@danielfett.de>
Date: Sun, 05 Nov 2023 20:08:37 +0100
MIME-Version: 1.0
To: oauth@ietf.org
References: <CAD9ie-sh0qnGzg5VwU_enq2Br9hH5zgm86z9i7vdMj_uQs=4yA@mail.gmail.com> <CAGBSGjrMDrXMd2ApKmLn_LVgMSLME-wvHqPCTpzgDxk5_+kRSA@mail.gmail.com>
From: Daniel Fett <fett@danielfett.de>
Content-Language: de-DE
In-Reply-To: <CAGBSGjrMDrXMd2ApKmLn_LVgMSLME-wvHqPCTpzgDxk5_+kRSA@mail.gmail.com>
X-Rspamd-Queue-Id: 4SNkXk1Yb6z9scm
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bYNPJwnwS1TPyX3loXk8jskIoUo>
Subject: Re: [OAUTH-WG] Cookies & headers in OAuth 2.0 Security Best Current Practice?
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Nov 2023 19:14:16 -0000

I agree with Aaron!

Also we should be very careful about any additions to the Security BCP 
at this point. It is very easy to re-start the "one more thing" loop 
we've been stuck in for the last years. There may be more useful things 
to say, but we should put them on the list for a future second version 
of the BCP.

-Daniel

Am 05.11.23 um 20:03 schrieb Aaron Parecki:
> I don't think the Security BCP should incorporate cookie best 
> practices directly in the document. If anything, it sounds like 
> possibly a candidate for inclusion in the Browser Apps BCP.
>
> There are already some mentions of these cookie properties mentioned 
> in the Browser Apps BCP, though only in reference to specific 
> architectures, not as a general best practice. For example:
>
> https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-15.html#pattern-bff-cookie-security
>
> Aaron
>
> On Sun, Nov 5, 2023 at 10:48 AM Dick Hardt <dick.hardt@gmail.com> wrote:
>
>     Hey
>
>     I was reviewing security on some sites I managed and checked to
>     see if the recommendations were in the BCP.
>
>     I don't see anything around cookies such as httpOnly, sameSite,
>     secure.
>
>     I saw some HTTP security header suggestions buried in 4.16
>     (X-Frame-Options, CSP), but not for Strict-Transport-Security,
>     Permissions-Policy, or X-Content-Type-Options, and the CSP
>     guidance is rather vague.
>
>     I understand these are general web security best practices, and
>     perhaps I missed it, but I think it would be useful to call out
>     that best security practices around cookies and headers should
>     also be followed in Section 2, and either have the best practices
>     included, or direct the reader where to find them.
>
>     /Dick
>
>     _______________________________________________
>     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

v2.23.0 | Report a Bug | By Email