[Some of you may have seen an earlier draft of this proposal before.
I originally sent it to secur...@mozilla.org and was asked to bring it
here.]
I've been following the mailing list for the IETF's "keyassure"
working group, which plans to standardize a mechanism for putting
application-layer server keys (or their hashes) in DNS, certified by
DNSSEC. TLS/SSL is the first target, and of course also the most
interesting for the Web.
While the current proposal seems sound technically, the WG has been
avoiding client policy -- there is a bit of policy in the current
draft, but it's worded vaguely enough to be (IMO) useless. I've
drafted a policy spec which I'd like to propose to the WG. However,
before doing so, I thought I would run it by y'all. If you like it,
perhaps we could present this as the Mozilla consensus position rather
than just one guy's opinion; if you don't like it I am eager to hear
why.
For reference, this is the current draft proposal:
http://tools.ietf.org/html/draft-ietf-dane-protocol-03
and the mailing list archives may be found here:
http://www.ietf.org/mail-archive/web/keyassure/current/threads.html
-- cover letter to WG begins --
I [We, Mozilla] would like to see the DANE specification's section 3
("Use of TLS certificate associations") expanded considerably. The
present text is a great improvement on having no policy at all (as in
earlier drafts) but is still vague enough that all client software
might not behave in the same way in response to a TLSA record set;
similarly, a server administrator might misunderstand the consequences
of adding a TLSA record to their zone. Without a clear, unambiguous
specification of client policy, I do not think DANE will offer any
security benefits. Therefore I have drafted a policy which is
suitable for the needs of Web security. It seems to me that it should
also suit other protocols secured with TLS, but I could be wrong, and
would welcome corrections.
We see four primary benefits from DANE to the Web, and our proposal is
written with them in mind:
* It could provide additional security in the presence of
untrustworthy "middleboxes", such as home routers vulnerable to
remote exploitation and conversion to MITM attackers.
* It could provide a mechanism for preventing the "suborned CA"
attacks described in <http://files.cloudprivacy.net/ssl-mitm.pdf>.
* It could provide an alternative to DV certification for sites that
currently opt to use self-signed certs.
* It could eliminate inconveniences and security-degrading workarounds
in the use of CDNs for TLS-secured content, such as very long
subjectAltName lists.
The proposal below is a complete replacement for section 3 of DANE.
Small wording changes would also be required in some other sections;
I am prepared to write those changes if the WG adopts this proposal.
-- proposal begins --
# Client application behavior when TLSA records are present
Clients that wish to make use of TLSA records in securing a connection
MUST be security-aware in the sense of RFC 4033. (In subsequent text,
it is assumed that the clients under discussion wish to make use of
TLSA records if possible.)
Clients MUST ignore TLSA records whose DNSSEC validation state is
"insecure" or "indeterminate". Clients MUST also ignore TLSA records
they do not understand (for instance, records with a cert type or hash
type they do not implement).
Clients that receive *any* "bogus" records for a server that they wish
to connect to (whether or not this affects a TLSA record) MUST NOT
proceed with the connection.
Clients that receive a "secure" TLSA record for a server MUST treat
this as an assertion by the zone administrator that *only* end-entity
certificates that can be associated with the domain name, according to
the procedure in section 2.1, are legitimate. Therefore, if a client
receives a secure TLSA record, and subsequently receives an in-band
certificate chain that does *not* match the record, it MUST reject the
certificate and abort the connection. This rule applies even if the
in-band chain would have been trusted in the absence of TLSA
information.
Clients SHOULD NOT allow users to force a connection under any of the
conditions described in the previous two paragraphs. A client that
has good reason not to comply with this requirement (for instance, a
forensic tool) SHOULD treat all content received over a forced
connection as actively malicious; in particular, no downloadable code
should be executed, and nothing in the content should trigger further
network traffic without explicit user instructions.
Clients MAY treat a "secure" TLSA record as providing positive
assurance that a certificate is valid. However, if a client receives
a secure TLSA record, then a certificate chain that matches the record
but, in the absence of a TLSA record, would have been rejected for any
reason other than lack of a trust anchor, it SHOULD still reject that
certificate. (For instance, a certificate that has been revoked by
its issuing CA SHOULD be treated as revoked even if it is assured by a
TLSA record.)
Furthermore, clients SHOULD NOT treat a TLSA record as assurance for
any fields of a PKIX certificate other than the following: [list here]
In particular, a TLSA record MUST NOT be treated as providing EV
assurance. Clients that wish to distinguish EV certificates MUST
still validate them by means of a CA trusted for that purpose.
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
