On Tue, Apr 16, 2013 at 07:57:09PM -0400, Richard Barnes wrote:
> +1
>
> Plus, this is for TLS, and in TLS, the server is required to present a cert
> chain. So the situation cited in the erratum can't happen.
This is false. There is no pre-DANE requirement for servers to
present a *complete* chain, they may for example omit the root CA,
since prior to DANE, the client always needed that on hand.
On Tue, Apr 16, 2013 at 04:17:09PM -0700, John Gilmore wrote:
> I think it should be rejected.
Note, the erratum only suggests requiring the server certificate
when the TLSA RR is a *digest*, so "2 0 0" and "2 1 0" were never
in scope.
> The issue is certificate usage "2", defining a new trust anchor.
Via a digest of public key material.
> To make a system interoperate with DANE-TLS clients when publishing
> TLSA records that specify usage 2, a server operator and domain
> administrator must:
>
> * Supply the entire trust anchor certificate in their TLSA record,
> specifying selector 0 (full certificate) and matching type 0
> (exact match); or
Not in scope for the erratum.
> * Configure their TLS server to supply the relevant trust anchor
> certificate in the certificate list that it sends [the option
> that Mr. Dukhovni suggests]; or
Correct.
> * Supply the public key of the trust anchor in their TLSA record,
> specifying selector 1 (Subject Public Key Info) and matching type 0
> (exact match), allowing any certificate(s) signed by the trust anchor
> to be validated; or
Not in scope for the erratum.
> * Only interact with clients who already have a copy of the trust
> anchor certificate or public key. Some applications may be
> designed or configured to work only with a restricted set of
> clients.
Then the specification should say so. That is, either the server
operator intends to *only* support pre-configured clients, or the
server operator MUST include the TA certificate in the server chain.
My concern is that many server operators have a weak grasp of
cryptography, and may naively expect "2 1 1" or "2 0 1" to work,
since they specified the TA in their TLSA record, (surely that's
enough :-).
> Any or all of these options are valid and will result in DANE-TLS
> interoperability. The erratum should be rejected.
For SMTP prior to DANE, TLS is either never used or used
opportunistically, so the server operator will continue to receive
email from DANE-unaware clients for years to come.
Not publishing the TA certificate is not an access control mechanism,
it just complicates client implementation even for clients that have
a copy of the TA certificate somewhere.
Augmenting the server chain with TA certs by digest is rather
non-trivial as these can be anywhere in the chain, but OpenSSL,
for example, only stores self-signed roots in the trust store.
Supporting out-of-band TA certificates is rather non-trivial. The
proposed language makes the protocol more robust and easier for
users to understand and implement correctly.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
