On Thu, Jun 11, 2009 at 10:34 PM, Mark Andrews<marka(_at_)isc(_dot_)org> wrote:
In message
<a123a5d60906111838t460ca168l9cf797a486ec1cf1(_at_)mail(_dot_)gmail(_dot_)com>,
Phill
ip Hallam-Baker writes:
So we have totally abandoned the idea of doing DNSSEC in the end point clie=
nt?
Trust roots have to be valid for at least a decade to be acceptable to
the application vendor community.
That's a unproved assumption.
It is an observation backed by fifteen years of experience and direct
conversations with the principals for cryptographic security at the
major platform vendors.
Moreover, I note that far from soliciting opinion from these groups,
the DNSEXT working group has done everything it can to drive such folk
away.
Every single time a real world deployment constraint has been raised,
the response of the group has been fingers in ears 'LA-LA-LA NOT
LISTENING'. It took two years of argument before the zone walking
issue was accepted as a legal requirement, it took five to get support
for opt-in.
At each stage in the proceedings, the length of time that the process
has taken is used to avoid considering real world deployment
constraints.
You think that you are finished. All you have done so far is to build
PEM. PEM got to the exact stage that DNSSEC has got to thus far in a
quarter the time. They had a complete set of RFCs specified that
described a scheme that nobody could deploy. Their excuse was that
nobody understood the deployment constraints.
And even though the current model of network administration is to
constantly fiddle with everything, I think that is going to have to
stop.
Lots companies already use private roots. Equipment
manufactures are not going to build equipment that can't
be used by those markets.
Manufacturers are quite capable of producing only checklist compliance
for features that have no customer demand.
I talked to analysts from Gartner, Burton and others at RSA this year,
none considered DNSSEC to be a major security issue. They write the
RFPs that drive feature support.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf