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

From: Chris Newman <[email-masked]>
Date: Thu, 14 Apr 2016 09:54:41 -0700

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?

		- Chris

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 14 Apr 2016 17:56:35 +0100

Hi Chris,

On 14/04/2016 17:54, Chris Newman wrote:
> 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).
>
> 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

---

From: Mark Risher <[email-masked]>
Date: Thu, 14 Apr 2016 18:16:20 -0700

I like the idea of the shared registry (option 2). Let me know if there's a
particular way we should reference it in the SMTP STS draft.

/m

--
Mark E. Risher |  Group Product Manager |  [email-masked] |  650-253-3123

On Thu, Apr 14, 2016 at 9:56 AM, Alexey Melnikov <[email-masked]>
wrote:

> 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).
>
> 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.
>
> 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.
>
> pursue that option as it’s a fairly significant change to MUA STS. Comments?
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 15 Apr 2016 16:19:37 +0700

Hi,

> On 14 Apr 2016, at 23:54, Chris Newman <[email-masked]> wrote:
> 

This makes a lot of sense.

> 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?

But it's a good point that #1 would get MUA-STS out of the door sooner, which is something I'd very much like to see deployed. Difficult, but I think option #2 is the way to go.

Thanks for working on this,
Aaron