23 apr 2013 kl. 01:06 skrev Viktor Dukhovni <[email protected]>:
> 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, THanks. This is a lot to digest and I'm sure I'll come back with details. A quick overview of SIP and TLS: - the phone connects to the "home proxy" or an "outbound edge proxy" using TLS. The display can here act as a web browser. - The phone place a call to another domain. The proxy now sets up connections that work like SMTP - hop by hop. NAPTR records indicate if TLS can be/should be used to reach another domain. - There is a SIPS uri that forces TLS in all hops. It's mostly considered deprecated. - There are no error messages to indicate validation failures back to the phone if a hop fails. - To sign caller identities and other message headers, a special standard called SIP identity (not S/MIME) is used. The certificate for this is published using HTTPS, binding a possible self-signed private CA to a public PKI used for the HTTP server. This is all for signaling. Media encryption keys is handled by DTLS. In SIP the binding between the SIP uri (like sip:[email protected]) and the server (sollentuna.example.org) is done by a cert that contain the subj alt name uri sip:edvina.net - not the server host name. As the SRV draft says, this is not very scalable for hosting providers and can change. The problem then is if a server doesn't support TNI the certificates for both DNSsec/DANE capable clients and legacy clients will be hard to set up and manage, which is not good in order to stimulate deployment. Now back to re-reading RFCs and drafts :-) /O _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
