Re: [TLS] Draft updates: tls-dnssec-chain

[Paul Wouters <[e-mail]>]

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