> On Apr 13, 2018, at 12:51 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
> Thanks for pointing this out. I agree that this text is likely to cause
> interop problems and should be removed or at least scoped out in
> the case where client and server are unrelated. I regret that I didn't
> catch it during my IESG review.
Well (B) is a proposal for doing just that, making it
possible for servers to suppress any such pinning, but it
also allows for future use-cases in which pinning might be
desirable.
If we're revising the text anyway, and given that implementors
suffer no burden to insert (on the server) or ignore (on the
client) an extra two bytes in the extension, (so Melinda's
issue of added complexity is not a barrier here), the sensible
responsive change is to add support for (B) with a requirements
that clients not pin longer than requested, and servers should
generally set the TTL to zero, unless pinning is understood to
be fit for purpose in the given application, and the operator
is willing to commit for the indicated time.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
