On Sat, Feb 28, 2015 at 5:27 PM, Mark Andrews <marka(_at_)isc(_dot_)org> 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.