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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf