Hi Phillip, Thanks for your message. I tagged my message with my name since I converted it to text.
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. [Hosnieh] Yes that is true. It is only authentication. However, CGA-TSIG only used TSIG as a carrier protocol because some people told me that in this case I would need minimum changes to the protocol and like other algorithms, I can only register a new algorithm with IANA for TSIG. Therefore it can be also a separate RDATA however, to avoid compatibility I just did not think about that. 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. [Hosnieh] True. 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. [Hosnieh] but for TLS you probably need to have CA or preconfigured your nodes with the list of trusted anchor. This is why I thought this binding would help to minimal configuration. 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. [Hosnieh] It is possible that use simply a hash of (IP + key), like the networks that doesn't support CGA or SSAS or like IPv4 scenario in CGA-TSIG. Sorry that CGA-tSIG name is a bit misleading and the first interpretation of this draft is the use of CGA. However, CGA is only one of possible mechanism introduced in the draft. 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. [Hosnieh] Do you have any suggestion for a simple implementations such as some required factors for implementations? I don't know how much this group would like to think about operational cases. Thanks, Best, Hosnieh _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
