On Tue, Sep 24, 2013 at 4:43 AM, Stephen Farrell <[email protected]>wrote:
> > Hiya, > > I've not seen mention of this so far here that I recall. > > Even as we improve the security of loads of protocols, there > will still be issues with meta-data monitoring based on > DNS queries for example. This point was sort of raised on > the IETF list e.g. in [1]. > > DNSSEC doesn't provide any confidentiality. There are > proposals that do try do that. > > Do we think this is worth looking at? > If so, anyone up for doing some work on that? > If so, how, or starting from what? > I have been looking at this for over a year now. Does anyone have issues with the following: * The communication between the client and the DNS resolver need not be the same as the protocol between the DNS resolver and the Authoritative servers. * System must offer fault tolerance with the client having access to multiple service points. * Use JSON over HTTP wherever possible * Individual DNS queries MUST result in low latency responses, this limits us to using UDP. * The scheme MUST work in ANY network configuration unless the provider takes explicit steps to block use. Therefore the scheme SHOULD support tunneling over DNS as an option but a clean protocol over UDP is better. * The scheme need not be limited to returning DNS information, if we have a long term security association between a client and a resolution service we can use it for speeding up access to OCSP data and much else if we choose. The above analysis led me to the following conclusion: http://tools.ietf.org/html/draft-hallambaker-omnibroker-06 This does not currently offer the UDP and DNS options but they are what motivated the following proposal: http://tools.ietf.org/html/draft-hallambaker-jsonbcd-00 There are important design differences between this proposal and CBOR. In particular JSON-B is a minimal extension of the JSON framework to add in efficient encoding of strings and binary data while CBOR is a rehash of ASN.1 without the schema. Note that the query currently supported is a replacement for the gethostbyname API call rather than a full DNS interface. The reason for this is that 99% of all applications only perform gethostbyname in the first place. The spec does allow a service to respond with a DNSSEC proof chain as advice on client request. Adding direct DNS queries to the spec is very simple, these can certainly be added if there is a desire for them. I would make one major change however and that is to support multiple DNS queries per request. One of the biggest limitations in the current DNS scheme is that it is only possible to query for one DNS record at a time or the ANY pseudo record which returns everything (and likely forces a TCP switchover). The requests actual applications want to make are things like the following: [example.com ? A, AAAA] [_http._tcp.example.com ? SRV, URI, URI2] Use of extended DNS features would be much easier if a client could tell the resolver to send back data for multiple queries at once. Moving to a pure UDP protocol allows requests and responses to be longer than 500 bytes. It is also possible for a single request packet to return multiple responses. These mean that it is very unlikely that fallback to TCP is ever going to be necessary for client queries where low latency is essential. It is however possible that a complex DNSSEC interaction might require a large amount of response data. -- Website: http://hallambaker.com/
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
