On Sat, 28 Apr 2018, Shumon Huque wrote:
TLS servers that do not have a signed TLSA record MAY instead return
a DNSSEC chain that provides authenticated denial of existence. This
specification does not require TLS servers to provide such a denial
of existence chain,
The second sentence is just repeating the MAY and is not needed.
But more importantly, it does not specify what the extension content
should be in the absense of a signed TLSA record and not wanting to
put in the denial of existene. Are you expecting an empty payload?
A single NULL payload? Or are you expecting the extension should be
omitted entirely? And what is the expected client behaviour in that case?
otherwise it could not be deployed incrementally
in environments where not all TLS servers support this extension.
It can be deployed incremendally as Viktor, Nico and I have shown
repeatedly with a two byte value.
Authenticated denial chains include NSEC or NSEC3 records that
demonstrate one of the following facts:
o The TLSA record does not exist.
o There is no signed delegation to a DNS zone which is either an
ancestor of, or the same as, the TLSA record name.
"s/one of the following facts/either"
In the absence of such a proof, a TLS client
misdirected to a server that has fraudulently acquired a public CA
issued certificate for the real server's name, could be induced to
establish a PKIX verified connection to the rogue server that
precluded DANE authentication. Application ecosystems where all TLS
servers are expected to implement this extension could require such
authenticated denial proofs to be delivered by TLS servers that don't
have signed TLSA records.
I think this belongs in the Security Section. It's a big security
problem and so should be explained in the Security Section.
> 3. Remove current text about pinning
* Remove client initiated pinning para from Section 8:
This paragraph was entirely deleted:
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.
Client applications could also employ a Trust on First Use (TOFU)
like strategy, whereby they would record the fact that a server
offered the extension and use that knowledge to require it for
subsequent connections.
And as stated before, removing this is not enough. You need to explain
what the expected client behaviour is when the extension appears and
disappears, either in this section, a seperate section, or the Security
Section.
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
