Zack,
I think having some kind of statement from the Moz community could be
helpful, and a good excuse for Moz folks to get up to speed on the spec.
With respect to the Section 3 text, it may be best simply to voice your
thoughts directly on the DANE list. I don't think the current text is
considered settled by the group. For instance, you can see my recent
message suggesting changes consistent with Matt's suggested text:
http://www.ietf.org/mail-archive/web/keyassure/current/msg00923.html
I think your suggestions below track similarly to Matt's suggestion, but
I need to take a closer look. I'd suggest we do this on the DANE list.
If DANE seems to settle on something, and Moz folks don't like it,
maybe we can coordinate on a counter-proposal.
Does that seem reasonable?
Cheers,
Steve
On 2/1/11 12:52 AM, Zack Weinberg wrote:
[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 .
* 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 al
