Re: [Uta] STS directive registry: separate or shared?

Alexey Melnikov <alexey.melnikov@isode.com> Thu, 14 April 2016 16:58 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8744C12E2D6 for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 09:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Level:
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com
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 vSXQ9I8M9BHY for <uta@ietfa.amsl.com>; Thu, 14 Apr 2016 09:58:23 -0700 (PDT)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id B2F0412E11C for <uta@ietf.org>; Thu, 14 Apr 2016 09:58:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1460653102; d=isode.com; s=selector; i=@isode.com; bh=7s3us7E7fblTFGjaGAK4m8BVwTVSPOSnPjQBQJn81vA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=nzltoiyyiY+5dIYB9lxX7Wya0UvPxS65pO7PIpuvexLyTjlto25yPl7lsQGXS/oZKAyU15 53dno6UhsIwkRqiYoXEn85cFojyAQ380X7htENMC4LjEYxcpyobJMFGlPkYANi5r5/xNGK 7L1jqINZA8LoUeC/vOPnO16e1zFG+3A=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <Vw=MLgBntBkD@waldorf.isode.com>; Thu, 14 Apr 2016 17:58:22 +0100
To: Chris Newman <chris.newman@oracle.com>, "uta@ietf.org" <uta@ietf.org>
References: <etPan.570fcb56.1b83edb9.17026@dhcp-amer-vpn-adc-anyconnect-10-154-168-221.vpn.oracle.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <570FCBC3.6030304@isode.com>
Date: Thu, 14 Apr 2016 17:56:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <etPan.570fcb56.1b83edb9.17026@dhcp-amer-vpn-adc-anyconnect-10-154-168-221.vpn.oracle.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------040601060402050200030202"
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/RAlrKztGxk1hUD59F-E3pVOnQsA>
Subject: Re: [Uta] STS directive registry: separate or shared?
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 16:58:25 -0000

Hi Chris,

On 14/04/2016 17:54, Chris Newman wrote:
> Right now we have 3 STS proposals: HSTS, SMTP relay STS and MUA STS 
> (DEEP).
>
> HSTS described its extensibility model, but punted on actually 
> creating a registry. A registry covering HSTS would be useful because 
> there’s at least one limited-use directive in the wild in addition to 
> those in the HSTS base spec. MUA STS currently describes an 
> extensibility model and creates a registry just for itself. SMTP relay 
> STS is missing both an extensibility model and registry, although 
> Viktor has made a compelling case that we we want to be minimal on 
> SMTP relay STS directives (at least initially).
>
> There are two ways to move forward:
>
> 1. Each protocol is responsible for it’s own extension model and 
> registry. This has the advantage of getting MUA STS done sooner, but 
> we’ll probably end up with 2 or 3 separate registries with some 
> redundancy and potential for semantic conflicts in STS directives with 
> the same name between protocols.
>
> 2. We create a combined STS registry that includes a 
> protocol-applicability field for each directive. Some directives would 
> be multi-protocol (e.g., max-age may be shared between HSTS and SMTP 
> relay STS), most would be single-protocol initially (that could change 
> later). One advantage to this approach is it gives us a place to 
> include some prose about why STS proposals are different and why 
> different applicability is important. But this would take a bit longer 
> and mean the WG would have another draft. This would make life 
> slightly simpler for SMTP relay STS as it would just have to describe 
> its extensibility model and point to the shared registry. If we do 
> this, I am willing to co-author the shared-registry spec and Jeff 
> Hodges (co-author of HSTS spec) is also willing to co-author the spec.
>
> I lean slightly towards option 2, but we need a WG rough consensus to 
> pursue that option as it’s a fairly significant change to MUA STS. 
> Comments?
>
I think I prefer option 2 or at least I would like to see us try. I am 
happy to help with this.

Best Regards,
Alexey