On 2011-02-05 1:13 PM, Nelson B Bolyard wrote:
Zack, thanks for bringing this to this list/group. I think many of us
were caught by surprise by it, because it is a browser policy proposal
rather than a technical discussion of the protocols.
Personally, I was a little surprised to be asked to discuss this here
rather than a more policy-focused group.
Technical details of DANE are still up for discussion in the working
group; if anyone feels like it, I would say that the present argument
over exactly where in the DNS namespace TLSA records should appear, and
whether or not TLSA should be coupled to some sort of service discovery
mechanism, is in need of feedback from people who implement TLS-based
application layer protocols. I, however, am mostly interested in policy.
> Some of us have
not been following the DANE work actively, and will need some time to
read up on it and appreciate all its implications. Quite a few of us
are (or, have been) die hard PKI advocates and some have seen DANE as
an attempted threat to PKI. I think some of us have hoped it would fail
and go away, but it seems to be becoming a juggernaut, and I think
those who ignore it do so at their own peril. With regard to NSS, I think
that if NSS ignores it, and is found to not adequately facilitate the
implementation of DANE, it may become irrelevant.
I have been trying to stay out of any PKI versus DANE arguments, and (as
you may see from the proposal) I still see a role for "traditional" CAs
in providing additional validation beyond "the server for this DNS name
should be using this public key". However, I wouldn't especially miss
the current state of affairs with DV certification if DANE totally
supplanted it.
1) I suggest you eliminate the word "bogus", replacing it with a much more
precise description of records that MUST NOT be trusted in the
establishment of a connection. Bogus is too open to interpretation, which
can only lead to future disagreement.
"bogus" in this case is a term-of-art defined by RFC 4033.
# Bogus: The validating resolver has a trust anchor and a secure
# delegation indicating that subsidiary data is signed, but the
# response fails to validate for some reason: missing signatures,
# expired signatures, signatures with unsupported algorithms,
# data missing that the relevant NSEC RR says should be present,
# and so forth.
I think deferring to that document for definitions of DNSSEC validation
outcomes is what the IETF is going to want.
2) After 14 years of working on SSL/TLS for browsers, I can tell you that
browsers will all ignore the paragraph that says "Clients SHOULD NOT allow
users to force a connection ...". I suppose that surprises no-one.
If I have anything to say about it (and I intend to), Mozilla will *not*
ignore that paragraph. ;-) There's at least a little precedent in the
Strict Transport Security specs.
zw
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
