> On Apr 12, 2018, at 7:47 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> In the current document, there is no expectation that clients will pin the
> server's use of TLSA and therefore the server can safely stop using
> TLSA (or run a mixed server farm). However, because this text implies
> that the client *could* pin, in order to ensure interoperability the server
> would have to provide authenticated denial at the risk of connection
> failure with such clients. However the text also does not require that
> the server do so. Thus, a conformant client and a conformant server
> can fail if the server just stops using TLSA.
Another way of looking at this argument is that we should not recommend
that servers should return denial of existence, because if we do, then
servers that don't return denial of existence might find themselves less
interoperable than those that do. So everyone should be less interoperable,
so not that nobody is relatively disadvantaged.
An honest assessment of the situation is that indeed returning denial
of existence is more generally interoperable in the face of unknown
client behaviour, and so should be recommended as suggested.
I am only mildly sympathetic to the slippery slope argument that this
may facilitate expectations of such behaviour in clients. We are not
here to police future design decisions for fidelity to pure
interpretations of the draft. If client expectations are desirable
in future applications, and servers coöperate, then hooray, we have
a specification that meets real world needs.
That said, the proposed language is not intended to be ann a-priori
license to "pin as you see fit" with no prior application-specific
standard defining what constitutes interoperable behaviour. This
specification provides a mechanism, not policy. Applications will
have to define the relevant policy options. My goal all along has
been to make sure that the mechanism is sufficiently flexible to
accommodate a range of application policies. [ Thus also the proposal
for the additional TTL hint, which supports a broader range of possible
policies. ]
If you'd like me to craft revised option (A) text, that includes a suitable
caveat, I can try. Or you or someone else can propose an alternative.
I only ask that it be honest about the server's options: serving the denial
of existence (DoE) records does interoperate with a broader range of client
policies.
In an application where the extension is absolutely optional, i.e. clients
MUST NOT (and do not in practice) expect consistent use by the server,
returning the DoE records would not be substantively different from simply
leaving out the extension. The client must be able to function in some
fashion with the extension missing, whether legitimately or stripped.
In applications where some clients expect downgrade protection the server
returning DoE records continues to work and the one not returning them might
not interoperate with clients that expect to consistently learn the truth
(good news or bad) about the servers TLSA records.
Does anyone want to propose better text?
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
