Re: [websec] Regarding RFC 6797

"Tobias Gondrom" <tobias.gondrom@gondrom.org> Tue, 15 May 2018 08:50 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4027112D77A for <websec@ietfa.amsl.com>; Tue, 15 May 2018 01:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); domainkeys=pass (1024-bit key) header.from=tobias.gondrom@gondrom.org header.d=gondrom.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IME08WyUJWyc for <websec@ietfa.amsl.com>; Tue, 15 May 2018 01:50:38 -0700 (PDT)
Received: from gondrom.org (www.gondrom.org [5.35.241.16]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3928A120721 for <websec@ietf.org>; Tue, 15 May 2018 01:50:37 -0700 (PDT)
Received: from seraph (ip-109-41-195-5.web.vodafone.de [109.41.195.5]) by gondrom.org (Postfix) with ESMTPSA id 4B6636499C; Tue, 15 May 2018 10:50:35 +0200 (CEST)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=yX1l5Hr5Gka9Zbtx4q++uk1rzijqaZEnXq1ZAXLu6Zf+bmf2r4h0VbWSGxILaHUyQtJagM4FvrZGiBqASRiRqJI+sFFMWF+3OEjiTx1v19e8UoPuyQSe0q4OZbXkVzavbK1K2Uw+I3qCX4NMfb5UojCAEklZJu+G2wMAXm4OxVc=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Content-Language:Thread-Index;
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
To: 'Anne van Kesteren' <annevk@annevk.nl>
Cc: 'Yoav Nir' <ynir.ietf@gmail.com>, 'Robert Linder' <Robert.Vuj.Linder@outlook.com>, 'websec' <websec@ietf.org>
References: <CWXP265MB03125F1F074DBA2FDA1E1D2BB1860@CWXP265MB0312.GBRP265.PROD.OUTLOOK.COM> <960CE667-98A4-48A9-9E7E-B32E3405A961@gmail.com> <CADnb78jDEfAwoeObF62SmdaxpF2FrYF2TQZGnESE+1kZEU=xNA@mail.gmail.com> <019e01d3eb9c$955927f0$c00b77d0$@gondrom.org> <CADnb78jWAO9APYA4MMgLYcXr4DBxQoVaapNfrVm_P-QqC7j2qQ@mail.gmail.com>
In-Reply-To: <CADnb78jWAO9APYA4MMgLYcXr4DBxQoVaapNfrVm_P-QqC7j2qQ@mail.gmail.com>
Date: Tue, 15 May 2018 10:50:31 +0200
Message-ID: <004301d3ec29$c8dc4750$5a94d5f0$@gondrom.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AQHsIF+VvDAWPRIEQoHKTVc3iukXtgLEtT3WAdYov9MBtCrIZAFNbIqPo8MuuEA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/websec/v8Rb2yNvuIfM5c47J_4jjUxYfGg>
Subject: Re: [websec] Regarding RFC 6797
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 May 2018 08:50:40 -0000

-----Original Message-----
From: Anne van Kesteren <annevk@annevk.nl> 
Sent: Monday, May 14, 2018 6:32 PM
To: Tobias Gondrom <tobias.gondrom@gondrom.org>
Cc: Yoav Nir <ynir.ietf@gmail.com>; Robert Linder <Robert.Vuj.Linder@outlook.com>; websec <websec@ietf.org>
Subject: Re: [websec] Regarding RFC 6797

>On Mon, May 14, 2018 at 5:59 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
>> I agree. Preload is probably the easiest way to go.
>> And the use case of transfer of domain ownership can not be ignored.
>>
>> Not sure whether preload really needs further standardization, after 
>> all there are only a few browser implementations out there.
>> However, if you think that is needed, feel free to drop me a message 
>> and we can write up a quick ID and publish it as individual ID.

> I think it'd be good to formalize that the preload keyword is used, cannot be used for something else, and what it's used for.

Do you think we need for this an individual RFC or would there be any simpler way we could achieve this? 
Best regards, Tobias