[websec] New Version of ESRV proposal for DNS based 'strict' security

[Phillip Hallam-Baker <[e-mail]>]

One of the discussions in Beijing centered on the desirability of supporting
strict security type mechanisms at the DNS level as opposed to the HTTP
level.

Here is a revised draft of the ESRV mechanism which is designed to provide a
comprehensive framework that supports Internet Services in general. It is
considerably simplified from the previous edition and the data formats have
been intentionally aligned with the separate CAA proposal.

http://www.ietf.org/id/draft-hallambaker-esrv-01.txt


The benefits of having a DNS approach are:

* Allows for downgrade protection on every connection, not merely secure
after first contact
* Consistent approach to downgrade protection across all protocols rather
than special casing HTTP
* Single point of administration for network related properties.
* Allows the task of establishing the 'best' secure connection to be handed
off from the application programmer to the platform provider and the host
administrator.

The disadvantages are

* Depends on DNSSEC deployment at the target domain
* Longer time to market

Given the urgency of 'strict' security, I see this proposal as being
complimentary to rather than as a replacement for the in-band approaches
already proposed.


The area I would see as being an early adopter for this approach is Web
Services. In particular it would allow future versions of Perl and Ruby etc.
to provide an Internet API that allows mashups to easily establish the
'best' connection to a Web Service instance according to well defined
criteria.

While security is my motivation for doing the work, I have learned that
performance and ease of administration are better marketing propositions.
Hence the bulk of the draft actually concentrates on the problem of how to
enable Web Service protocols to move from round robin DNS as a load
balancing mechanism to using SRV and URI based discovery.



The G/ESRV proposal does not address the question of trust anchor or key
distribution. That is clearly an important part of the overall problem but
one that we have already addressed in a separate proposal, CAA:

http://tools.ietf.org/html/draft-hallambaker-donotissue-02

As you might imagine, G/ESRV and CAA are intended to work together but the
timescales for the two are different. We designed CAA to pick the 'low
hanging fruit' where we knew we could make a significant difference in a
matter of months. While some parts of CAA do require client changes, there
are important and useful benefits that require no code to be deployed by any
party other than CAs who have a very significant incentive to do so.

G/ESRV is a more complex proposal with more moving parts and is going to
take time to develop. In particular it needs to be supported in both the DNS
community and the Web Services developer community.


Comments invited

-- 
Website: http://hallambaker.com/