On Sun, Oct 12, 2014 at 9:34 AM, Stephen Farrell <[email protected]> wrote:
> Just one point on one bit of this. TCPINC will be having > some of the same discussion as they consider the pros and > cons of the tcpcrypt proposal vs. some (D)TLS based ones. > While its quite possible that the cases are so different > that different conclusions ought be reached, I think its > clear that some of the analysis will be the same. So I hope > that DPRIVE and TCPINC chairs/participants try to save us > all a bit of time and energy by where possible factoring out > the generic parts of the argument from the DNS and TCP > specific parts. And maybe subscribing to both lists would > good for folks who care about the (D)TLS/generic-solution > vs. protocol-specific solution topic. I think we should also throw the TLS/2.0 discussion into the mix and ask why IPSEC is a failure. All these protocols have two major components. A key exchange and formatting. Getting the key exchange right is hard, getting the formatting right is fairly straightforward if you do it from scratch. Trying to make sense of a formatting designed for a different application makes it hard. Key exchange is the hard part to get right and can be shared. I originally designed SXS-Connect to allow me to establish keys for use in Web Services. But it could be used for IPSEC, DNS-PRIVACY, TCPINC, whatever. That said, SXS-Connect is right now just relying on the TLS key exchange. So I get reuse of TLS. But that limits the applications and the security. And I am rather unhappy with relying on TLS which is a transport layer security solution to protect application layer keys. So I really want to drop in a DH or EDH on top. DNSPrivacy does not actually need to do key exchange very often because a client should change its DNS service no more frequently than once a year (ESPECIALLY if it is a mobile device). And the client really does have to authenticate the service. No really, taking your DNS service from random servers is just so incredibly stupid I can't believe I have to point that out. So just co-opting the TLS stack is probably OK for that niche. TCPINC on the other hand is going to need more agility in making connections and unauthenticated connections are definitely in scope and acceptable. So engineering a custom key exchange would make sense. If you reuse TLS for key exchange then you might as well do TLS. But the crunch here is that we should not do a custom key exchange for TCPINC, we should design a module that can serve IPSEC/2.0, TLS/2.0 etc. So what do I mean by a key exchange? From a model point of view it has a choice of inputs but the output is always an identifier and a shared set of cryptographic parameters being algorithm choice(s) and shared key(s). The input could be the public key of a server, a pair of public keys, a symmetric key or nothing. So what I am arguing here is, yes we should try to do reuse. But please lets use something that is designed for reuse and not just take the cowardly way out and pick something familiar even though it is 20 years old and so complicated only a half dozen people at most really understand it. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
