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

From: Martin Rex <[email-masked]>
Date: Tue, 16 Feb 2010 23:21:09 +0100 (MET)

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

---

From: Alfred Hönes <[email-masked]>
Date: Tue, 16 Feb 2010 22:33:56 +0100 (MEZ)

Martin,

(1)  non-protocol issues

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

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:  [email-masked]                     |
+------------------------+--------------------------------------------+