On Thu, Apr 12, 2018 at 09:51:12PM -0700, Eric Rescorla wrote: > On Thu, Apr 12, 2018 at 9:40 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > > > On Apr 13, 2018, at 12:07 AM, Melinda Shore < > > melinda.sh...@nomountain.net> wrote: > > > > > > I'm okay with putting denial-of-existence in there as a should, > > > but I do feel strongly that pinning belongs in a separate document. > > > As I said earlier, I have a problem with putting features in protocols > > > that nobody intends to use. It's bad enough when it happens by > > > circumstance but doing it deliberately strikes me as a bad idea. > > > > The great irony of the situation, is that present draft already > > describes pinning: > > > > If TLS applications want to mandate the use of this extension for > > specific servers, clients could maintain a whitelist of sites where > > the use of this extension is forced. The client would refuse to > > authenticate such servers if they failed to deliver this extension. > > > > And I've seen no discussion or working group consensus to *prohibit* > > such pinning, only observations that it would be rather fragile in > > general. > > 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.
I think that means we'll end up with consensus to make a change, and indeed, we cannot not make some change. We can still debate whether to do (A), (B), (C), or, now, (D) (remove the text quoted by Viktor). I think it will be easier to get consensus for (A) or (C) than (D), though, of course, that's to be seen. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
