On Mon, Apr 22, 2013 at 05:33:18PM -0400, Warren Kumari wrote:
> So, when we were writing the DANE protocol document we decided
> to describe the general case and that there would likely be a whole
> set of "How to do DANE with $foo protocol" documents.
>
> Your mail backs up that decision, and also sounds like you are
> volunteering to start the "How to do DANE with SIP" draft...
>
> > following the wake of the
> > smtp work.
>
> or, better yet, in parallel with the smtp work? :-)
Amen. I think I am now able to articulate the root-cause of most of the
difficulty I faced reconciling RFC 6698 with SMTP, and it boils down to this:
- RFC 6698 assumes that TLS-capable application protocols that
will be adopting DANE TLSA, are currently using TLS in the context of
a largely usable (if creaking at the seams) public CA PKI.
* While I would posit that this assumption is not entirely
justified for browsers, in that the public PKI only "works" because
users are willing to "click OK" when often it doesn't, the real
source of friction is that this is far from true for other protocols
such as SMTP.
- Though RFCs 6394 and 6698 correctly aim to be application protocol
neutral, the operating model of 6698 s largely based on a
brower-centric mental model of TLS.
* RFC 6698 does not address the dichotomy between applications that
know they must do TLS, and are merely trying to do a better job of
certificate verification (e.g. https) versus applications in which
TLS support by the peer needs to be "advertised" by the server and
"discovered" by the client (e.g. SMTP), since the destination
address with SMTP does not encode channel security properties (as
it does with http vs. https URIs).
In SMTP before DNSSEC and DANE the TLS servers to be validated are obtained
from MX lookups via an insecure DNS, it is not possible to adopt the legacy
public PKI in this context, since checking the SMTP server's certificate for
the recipient domain fails when mail is hosted by a third party provider,
while checking for the MX host name is futile the MITM attacker controls DNS.
More fundamentaly, with a store and forward protocol, there is no interactive
user clicking "OK". So all the warts of the public PKI that are hidden under
that rug, become visible failures with SMTP.
Therefore MTAs largely ignored the public PKI, and do not come preconfigured
with a panoply of CA certificates they can't use except for the occasional
bilaterally negotiated secure-channel with a business partner (an ad-hoc SMTP
VPN over STARTTLS).
Therefore, when I look at the mandatory to implement certificate usages "0"
and "1", I see a standard that is out of touch with my reality. So I whine
and moan about about lack of the TA cert with "IN TLSA 2 x 1" or being
entirely unable to support "IN TLSA 0 x 1", low level issues with CNAMEs, ...
What I think I should do in the operational guidance draft, is to
identify the underlying causes, so that derived specifications and
application developers will be better able to understand what issues
they need to think about when specifying or implementing DANE for
their application or protocol.
If this ultimately leads to a 6698bis, perhaps there will be an opportunity
not only to clarify some not blatantly obvious formal consequences of the
specification, but perhaps to more closely examine some of the assumptions.
Perhaps, a revised standard might make certificate usages "0" and
"1" optional in derived application-specific standards, and thus
Tony Finch may be able to write an SMTP draft that is actually
usable by MTA developers (by mandating that SMTP MUST only use "2"
or "3" and provide the TA certificate with "2", which leaves mostly
some niggling over CNAMEs and perhaps other minutia to resolve).
Perhaps I tipped my hand too early, and should have waited until the draft is
written. I don't want to start a flame-war and will happily hide under a rock
writing the draft until the storm blows over if the above is too radical an
agenda for this forum.
If on the other hand some of the above makes some sense to you, please keep
it in the back of your mind, as there may yet be room to produce an update
to 6698 that:
- Discusses applications that can't (whether in theory or in practice)
make use of the legacy PKI.
- Provides guidance for protocols where TLS is discovered rather than
pre-ordained (the SRV draft attempts to do this, but the issue is
more general). When TLS support is not known in advance the presence
of TLSA RRs (even if all are unusable) acts as secure indication of
TLS support, so protocols where this applies SHOULD use TLS and not
plaintext in this case (which is not limited to SRV RRs).
- Considers the key-management implications of SNI, and perhaps gives
some ground or at least definitively rules me in the minority on the
CNAME issue.
- Anything else I may have missed, perhaps more insight from a SIP
perspective...
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
