Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
(Apparently, the subject lines have been messed up entirely
on this list these days. I tried to return to the actual
subject, GOST signatures for DNSSEC.)
I fear you are in danger of drawing the wrong conclusions based
on incomplete information.
(1) non-protocol issues
... that Zones can carry both, a mandatory to implement signature
(algorithm) and interoperable world-wide, and one that might
be prefered in particular regions (or legislations) and can
be evaluated in those areas by those who care (or which are
obliged to care).
If I understand correctly, the basic issue of those under GOST-related
regulatory restrictions is that they are legally constrained to
"MUST NOT use other algorithms than GOST to produce digital signatures".
That makes your smart proposal moot, AFAICS. :-(
But they don't need to create "digital signatures"!
They only need to provide RRSIG RRs with MACs that the rest
of the world can use to perform integrity checks and data
origin authentication based on a common asymmetric crypto
algorithm for the purpose of interoperability when validating
DNS records.
None of registries in Russia needs to provide official
"digital signatures" (in any legally binding sense) in order
to make DNSsec work at the technical level. The GOST-signed
RRSIG RRs can be the officially signed records, the other
is just a provision for technical interop of the MAC scheme
with DNSsec for the rest of the internet.
Any other approach just doesn't scale.
IIRC, IPsec decided somewhere around 1995 that sacrificing interop
to accomodate crypto export regulation was a dead-end road
and not appropriate for an international standardization body.
Although, I might have missed that the IETF reverted its attitude
and is today catering everone and his dog's personal crypto preferences
in their protocols, dropping the burden on the implementors of the
technology, I think it would be the wrong approach.
What is the situation in IPsec with regards to GOST these days?
(2) protocol issues
(are signatures and DNS KEYs in DNSsec really designed to be
"highlanders", i.e. there can only be one?)
No, DNSSEC can use and carry multiple signatures.
That's necessary for rekeying and algorithm agility (phased
introduction of new signature algorithms) anyway.
That's what I assumed (and I found it in rfc-4033 3.1).
The drawbacks are twofold:
- The protocol does not allow the clients to select what
they would like to get; they only can set a flag to say
"I do understand DNSSEC, please send the DNSSEC records
you have with the answer." So the authority or cache
needs to send all signatures to every DNSSEC-aware client.
That looks like a defect in the protocol.
- Keys and signatures add significantly to the size of
DNS responses, and there (still) are lots of obstacles
out there in the wild to proper use the protocol mechanisms
standardized long ago to cope with responses longer than
512 octets: EDNS, and DNS transport over TCP.
Too many network elements raise sad hurdles, and IP
fragmentation is a minefield.
Thus, widespread practice of regular double- (or triple-)signing
of DNS RRsets would most likely increase the order of magnitude of
failures to receive answers that lead to DNSSEC-verifiable results.
Hard luck. Sigh!
Probably the biggest mistake in DNSsec was to describe the data
that is used to verify RRs as "digital signatures" instead of
simply MACs based on asymmetric crypto algorithms.
All of the politics and flawed assumptions around PKI have prevented
the existing DNS registries to add RRSIGs to their zones many many
years ago -- which otherwise would have helped to iron out the
problems around the size of the DNS responses over the last decade.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf