On Sat, Feb 28, 2015 at 5:27 PM, Mark Andrews <marka@xxxxxxx> wrote:
And that is coming "_25._tlsa" and it uses DNSSEC to prevent the
downgrade. Whether your MTA uses STARTTLS or not is another matter
but we can prevent downgrade attacks from succeeding.
No it is not coming. The only way that can happen and be considered a secure proposal is to charter a new working group in the security area to work on a new security policy record to address the problem.
This is an important and difficult problem and one that the DANE working group declared to be OUT OF SCOPE.
Every time I tried to raise the issues I was told they were OUT OF SCOPE.
As a result TLSA is a dogs breakfast. It is a combination of the key publication mechanism the WG was chartered for and a security policy mechanism that wasn't really chartered but was done anyway but only in a half baked fashion.
This was my main concern with the DANE approach from the start. They would refuse to consider the general problem. Deliver a product that creates more problems than it solves when trying to solve the larger one and then insist that we use it because it is 'a standard'.
Well DANE has practically no deployment or traction so I don't see it as a fact on the ground that has to be worked on. This is a hard problem and it is a problem that is easier to address from a clean sheet of paper than one with a legacy support issue.
The way to address security policy for SRV type records is as follows:
1) Free the client end from the performance and data size issues imposed by the legacy DNS client-resolver protocol.
DPRIV is a really good opportunity to tweak the protocol so we don't have to worry about the client having to ask for multiple DNS RRs or that the results might not fit into 500 bytes or an ethernet MTU.
2) Define a new security policy record that is designed to work with SRV from the start and covers all the security policy concerns.
In particular make it possible to explicitly specify criteria such as 'use TLS transport' or 'XYZ authentication is required'.
The first change is the more important one and the fix is quite easy. Traditionally UDP DNS queries are one request packet and one response packet. This ensures that the services are idempotent and the resolver does not need to maintain TCP/IP connection state.
If we change the protocol so that a DNS request must still be a single packet but a response can have multiple response packets we preserve the connectionless, idempotent property while freeing ourselves from much of the impact of the MTU size constraint.