On Thu, Jul 13, 2017 at 03:01:04PM -0500, Stephen Checkoway wrote: > I don't think the WG should adopt this.
+1 > There are essentially two separate proposals in the I-D. Section 5 > proposes a slight change to TLS that results in no changes on the wire > and, as far as I can tell, is already allowed (but should probably be > discouraged) in the TLS 1.3 I-D. Thus, there's nothing for the WG to > do. > > Sections 6 and 7 propose a new protocol for distributing key pairs. > The use case is TLS, but it isn't specific to TLS and doesn't interact > with TLS (outside of using TLS for HTTPS). As such, I believe it's > outside the WG's charter. Agreed. Authors should make an ISE submission aiming for Informational, or just let the I-D expire and never bring it up again -- that would work just as well for me. The IESG could always direct the ISE to not publish. Given the lack of normative language in the proposed I-D, Informational is the only track that makes sense. What's to be gained by anyone in having this be a WG item anyways? A patina of legitimacy is the only thing I can think of. What's to be gained by anyone in having this be an RFC? A patina of legitimacy with which to flog it at implementors is the only thing I can think of. Legislatures elsewhere can always just legislate this sort of thing (think CALEA). But there's no reason the IETF should preemptively help such things along. I wouldn't be too annoyed if this gets published as an RFC because it's all obvious and could always get published elsewhere anyways. Refusing to publish here won't keep this sort of thing from getting specified and implemented. But there is no need for the IETF's help in the matter. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
