> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey <j...@salowey.net> wrote:
> Concerns have been raised about the trade-offs associated with pinning
and I do not think we currently have consensus to add pinning. While I
think it may be possible to come to consensus on pinning I think it may
take some time. I believe we can quickly get consensus for the following
approach:
>
> 1. Scope the document to the assertive use cases
> 2. Explicitly allow (but do not require) DoE be included
> 3. Remove current text about pinning
> 4. Re-submit the document for publication and start work on a separate
extension that supports pinning
Hi Joe,
Here is the proposed text for items 1, 2, and 3. It's also in the
tls-wg github repo. We'll probably tweak and wordsmith some more,
but this is the gist of it.
> 1. Scope the document to the assertive use cases
* Added scope description to Intro:
This specification can also be used to optionally convey
authenticated denial of existence of TLSA records. Restrictive uses
that might require such proofs (such as the PKIX constraining modes
of DANE, or where DANE should always be preferred over other modes of
authentication such as traditional PKIX) are thus not in its intended
scope. Such restrictive uses can however be supported
opportunistically.
> 2. Explicitly allow (but do not require) DoE be included
(Note: I've noticed Viktor has submitted some expanded text
describing denial of existence. We'll review and likely incorporate
much of that)
* New section: 3.4.1, that permits but doesn't require authenticated denial:
3.4.1. Support for Authenticated Denial of Existence
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, otherwise it could not be deployed incrementally
in environments where not all TLS servers support this extension.
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.
* Text in Section 8 (Mandating) that rewrites language that in the
previous draft stated that it doesn't support denial of existence:
This protocol allows TLS servers to prove that they don't have a
signed TLSA record by returning a denial of existence chain.
However, as explained in Section 3.4.1, it does not require TLS
servers to do so. 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.
> 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.
Thanks,
--
Shumon Huque
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
