On Mon, 2017-06-19 at 19:31 -0400, John C Klensin wrote:
--On Monday, June 19, 2017 21:26 +0300 Yoav Nir
<ynir(_dot_)ietf(_at_)gmail(_dot_)com> wrote:
...
By the Postel principle, the receiver should accept this
chain. In practice I might limit it to a lower number, because
I assume nobody does that. I think it's best for the
specification to say that "MUST support a chain of at least
7 and MUST NOT send a chain longer than 7", and of course
you'd have to say that profiles may further reduce this
number (for IoT).
It seems to me that your example, and some others, suggest that
if the principle was being stated today, it would be "be
conservative about what you send and liberal about what you
accept, but nothing justifies violations of common sense or
taking actions that would create risks". If the latter/new part
is really needed, we may be in worse trouble than with questions
about what the principle really means or even whether Jon was
right or wrong.
Yeah, as the joke goes, common sense isn't. Even assuming it's
prevalent, if you run a survey at the next TLS meeting what is a
reasonable limit for the length of a chain, you'd get a bunch of
different answers. Mine would be 10 because I have seen a real 7-cert
chain in production, but before that I might have said 4 or 5.
Without specifying it any sender has to be really conservative, maybe
limiting themselves to 3 in case there is some receiver out there that
is making severe assumptions. Without this being specified we end up
with receivers planning for 10 and senders limiting themselves (and
their PKI) to 3. This is not optimal.
I am not sure what the take away is. On the one hand under-specifying
creates interop failures, security issues and much complexity to address
issues and fix interop with old and new implementations. On the other
hand, the most successful protocols had a lot of wiggle room, and I
don't think this is coincidence.
Yoav