On Wed, Apr 17, 2013 at 02:59:42PM +0200, Martin Rex wrote:
> Paul Hoffman wrote:
> >
> > Viktor Dukhovni <[email protected]> wrote:
> >>
> >> The digest alone cannot direct directly
> >> be used to validate any chains, since we can't check the TA signature
> >> given just a digest of its certificate or public key. ]
> >
> > Correct. But that still does not mean that the TLS server needs to send it.
>
> In which case this will result in an interop problem.
>
> The purpose of IETF RFCs/specification is to promote interop.
> Any information that will generally be necessary to obtain interop,
> and that is lacking from an RFC/specification, is a defect in of the
> omission kind.
That was my motivation for proposing the erratum. That said, I am
not a pedant with respect to the form in which the interoperability
requirement appears in the standard.
Though I think that a MUST is appropriate, perhaps the possibility
of interoperability under some narrow circumstances (pre-configured
clients) makes the TA cert optional in those circumstances and thus
not an absolute MUST in general. Nevertheless, in practice,
interoperability on the public Internet requires the inclusion of
any usage "2" root CA in the server chain.
> The intention, and default operational model of DANE is
> (or at least should be), that it works as soon as the DNSSEC key
> bootstrapping has been solved, the server's zone has been DNSSEC enabled,
> and a TLSA record has been configured.
>
> While it is OK for a TLS client to pin a server cert or certs from
> the server's certificate chain in addition to DANE, or have any of
> those certificates pre-loaded, that is an *ADDITIONAL* TLS client option.
> It would be silly to assert that such extra complications would be
> the default DANE operational model.
Thanks, I agree. I find the counter-examples to be contrived,
focused on narrow use-cases when I see the purpose of DANE to be
broad Internet adoption. One does not really need DANE in small-scale
intra-mural environments, and on the public Internet the "MUST"
seems obvious. Once again, if it is preferable to express this
requirement as operational guidance rather than normative language,
I don't mind, so long as the requirement is ultimately clear to
server operators.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
