On Wed, Apr 17, 2013 at 01:03:54PM -0400, Richard Barnes wrote:
> Fair enough. But the upshot of this is that the server needs to EITHER:
> (1) Provide the cert in DANE, OR
> (2) Provide the cert in TLS
Or even as some have argued.
(3) Communicate only with clients that have obtained the cert by prior
arrangement.
> So it is completely plausible for DANE to have a mode where only a hash of
> the cert is presented. As Paul notes, this is deployment guidance, not a
> gap in the DANE protocol.
I don't agree with Paul, but I don't much care about the niggly
details. Some text should be added to 6698 that makes this potential
problem clear to implementors. I've added such text to the server
certificate seciton of the Postfix TLS_README, but this only covers
a subset of server operators.
The practical requirement when the association is a digest (which
rules out (1)) to necessarily do (2) (except in narrow cases when
(3) is an option) should IMHO be explained *somewhere* in 6698.
> That said, it might be worth starting a document to collect deployment
> recommendations of this type. Especially if it were written by people
> actually deploying DANE :)
This issue goes beyond a deployment recommendation, it is a logical
pre-requisite for interoperability that is easily missed when one
does not carefully analyze what the client needs to do in order to
use the TLSA RRs in question. Therefore, it should I believe be
added to 6698 in some form. If "MUST" is too strong for (2), given
the occasional possibility of (3), then a more nuanced wording is
fine.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
