Re: draft-ietf-dnsext-dnssec-gost [Was: Re: IAB statement on the RPKI. ]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Martin,

(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.  :-(

I have no idea whether or not geo-diversity of secondary
servers and/or anycast server instances providing signatures
with a generally accepted signature algorithm on the same zone
content could be an option ...
-- routing might do the "right" thing, and the necessary details
for the root could be worked out ...


(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.

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.

   -  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!


Kind regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@xxxxxxxxx                     |
+------------------------+--------------------------------------------+

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]