On Mon, Oct 27, 2014 at 10:45 AM, Paul Hoffman <[email protected]> wrote:
> On Oct 27, 2014, at 7:36 AM, Hosnieh Rafiee <[email protected]> > wrote: > > > So why do you think it is distraction for the WG that addresses privacy? > > I said I thought it was a distraction; discussing it further would be more > of a distraction. > Which is not a polite or acceptable fashion to deal with a proposal. Like many people I have been looking at applying TSIG more generally for many years. I think the approach is architecturally sound from a security point of view but it isn't a complete solution and when you start to extend it to meet the use cases here it soon becomes apparent that reuse is hurting more than helping. TSIG is only authentication so you have to add encryption. And the original TSIG assumed keys would be passed out of band so it needs a key exchange. So lets divide the protocol into two parts, a key exchange that establishes a shared secret and some form of packaging that applies encryption and integrity operations to the DNS messages. The second part is straightforward. People can agree or disagree as to whether my attempts to optimize the transport for DNS deliver worthwhile benefits, we can argue over the specific encoding (I picked the TLS schema). But what is clear is that it should be very simple to describe and implement or its being done wrong. The key exchange is the place where the design choices come in. And here we have two approaches: 1) Reuse something already existing (CGA-TSIG, DTLS). 2) Write something new designing it so that it could be reused elsewhere. I believe the second course is the best approach in this case. I am not re-inventing the TLS crypto but I am presenting it as a JSON web service in a way that allows for reuse. CGA does not meet the use case requirements I see for the Enterprise where it has to be really easy to bind a device to a DNS service. For embedded devices it has to be 'scan a bar code' level of simplicity. And I know that we are not talking about those use cases now. And I don't really want to have to talk about those cases now either. Instead I want to have a mechanism that can be implemented very simply to meet most of the use cases and can be extended later as needed.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
