> 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.
Section 8 already says that some clients may require the extension.
Providing denial of existence improves interoperability when all
that the client requires is the extension, and given denial of
existence might accept something else.
Servers that support the extension really ought to provide denial
of existence, if that's all they can do. Rather than suppress the
extension, if the client demands the extension and the server can't
provide it, interoperability is lost either way.
If your concern is that the new text is "license" for the clients
to arbitrarily require the extension in applications where servers
have no reason to expect such behaviour, I have no objection to
text that says that "the foregoing does not constitute a license
for clients to require the extension where this is not expected
application behaviour" or some such.
The idea is however to encourage servers to provide the denial
of existence, because it may be useful, and is not less interoperable
than eliding the extension. Giving license to clients to then
expect this from servers is not the intent here. I'm trying to
sneak in underhanded pinning. That's not the goal.
I'd like to see explicit pinning (or not) hints from the server,
so we don't need to play guessing games. Servers that consistently
return a TTL of zero would then be at liberty to drop the extension
rather than deliver DoE (denial of existence) at any time.
In your shoes I'd strongly advocate for the pin TTL, and make sure
that it is set to zero by any servers that be sure to avoid the
concerns that you're expressing. That way we don't have to play
guessing games about client behaviour.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
