> 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.
What my proposal (B) (really (C), since (B) requires (A) as a foundation)
provides first and *foremost* is the ability for servers to DISABLE
pinning, by giving clients an upper bound pinning TTL of 0.
If you don't want to see pinning, voice your support for (B) (really C)
and have servers send a TTL of ZERO!
Keep in mind that the proposed TTL is an upper bound, it is NOT an
obligation to pin, and therefore is always a restriction on pinning,
while at the same supporting a signal that pinning may be safe at
the server's discretion.
So this both serves the overall interoperability objectives voiced
by Eric Rescorla, allows servers to disavow any pinning and supports
future cases. It is a win-win, and carries ZERO implementation cost,
on the server, if pinning is explicitly unwanted, just the field to
zero and move along. On the client if no pinning is desired, just
ignore the TTL. This feature is a win/win and carries no implementation
burden, and the document is about to get a revision for (A) and still
awaits an IANA code point assignment.
If we act promptly on both (A) and (B) (i.e. (C)) there'll be zero
additional delay.
I sympathize strongly with the desire to keep specifications lean
and mean, but that desire is misplaced here. The technical details
do matter, and both supporting DoE and setting a max "pin" TTL are
well motivated, improve interoperability and allow the server to
opt-out of the sort of fragile ad-hoc pinning described in the draft.
So please, let's not allow the general argument to deafen us to the
specific context of this document. Though it needs at least (A) it
also needs (B) (i.e. (C)).
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
