Subject: Re: DNSEXT WG Last Call: SIG(0)

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Mon, 10 Apr 2000 11:36:10 -0400

From:  Terry Lambert <[email-masked]>
Message-ID:  <[email-masked]>
Date:  Wed, 08 Mar 2000 09:31:29 -0800
To:  Brian Wellington <[email-masked]>
CC:  "Donald E. Eastlake 3rd" <[email-masked]>,
            Olafur Gudmundsson <[email-masked]>, [email-masked]
References:  <[email-masked]>

>Brian Wellington wrote:
>> On Tue, 7 Mar 2000, Donald E. Eastlake 3rd wrote:
>> 
>> > Actually, although multiple different authorization was the only
>> > reason I mentioned when we last talked about this, there is another.
>> 
>> OK.  My primary concern is that situations involving multiple
>> authorizations don't arise.  Restricting it in SIG(0) seesed like the
>> logical choice, but maybe not.
>
>
>I think the key jitter argument is specious; I personally
>use SecurID, from Security Dynamics, to get behind an IBM
>firewall.  This works by generating pseudo-random numbers,
>and providing a window for "jitter" to deal with the clock
>synchronization issue for the pseudo-random number (e.g.,
>the number is valid for ~3x the window, and the back end is
>synchronized ("recentered") on the middle of the window for
>a valid number.

I also have a SecurID, although in my case it is for getting behind a
Motorola firewall.  However, that has nothing to do with the SIG(0)
key rollover case.  SecurIDs display a keyed function of time and do
not do any key rollover.  In the case of real key rollover, you either
have to try multiple private keys at the signer or be able to try
multiple public keys at the verifier.  And, in fact, multiple public
keys can be configured and multiple private keys can be tried
successively, even when multiple signatures are not allowed in one
message.

>This argument is specious for automatic systems, since
>there are no automatic systems that implement this (the
>SecurID system is to permit people with keychain fobs
>and an account and PIN to login from outside, not one
>machine with magic client hardware to talk to another
>with magic server hardware; I also think that permitting
>the implementation of a "standards conforming" system
>that is nevertheless non-interoperable with other
>instances of "standards conforming" systems is an extreme
>error, and points up an obvious flaw in the standards
>document, if it is even theoretically possible to create
>such an implementation).

We are talking about configuration here.  In IETF security protocols,
the norm is to have mandatory to implement algorithms which will allow
parties to interoperate if those algorithms are enabled, proper keys
are configured, etc. But it is entirely permissable to implement
optional algorithms from the standard or proprietary algorithms and it
is permissable to operate with the mandatory to implement algorithms
disabled or with no interoperable keys configured for them, etc.  For
example, in TKEY, you can have Diffie-Hellman (DH), the mandatory
algorithm, implemented and enabled at both ends and DH keys configured
at both ends but if they are not compatible (same modulus, etc.), then
you can't use them to negotiate a shared secret key.  But forcing
everyone to use compatible keys makes that modulus a much more
tempting target for attackers and if it were broken you would lose all
security...

Requiring all parties to not just implement but also enable and
configure interoperably keys for the one or occasionally two mandatory
algorithms has been viewed as unrealistic and insecure by causing
excessive reliance on and great difficulty in changing from the
mandatory algorithm.

>It seems to me that the "jitter" argument is an attempt to
>dodge the key distribution problem, which I believe has
>already been adequately resolved elsewhere (e.g. "Racoon"
>for IPv6), and we can look elsewhere for a model.

DNSSEC is a key distribution system.

All systems with real key rollover potentially have this problem.  If
you are, for eample, X.509 certificate based, you have questions about
time synchronization, verifying old signatures, how many keys are
valid at any one time, etc.  These are all soluble, for X.509 certs as
well as for DNSSEC, by generally having only one private key you are
signing with at any particular time but being able to verify
signatures by the current and previous and/or future key (s).  In
DNSSEC this can be accomplished by having multiple KEY RRs if you are
near a rollover.

>For the non-"jitter" argument of multiple algorithms, I
>think that if a client has an unsupported algorithm, then
>it should attempt it, and if the server does not accept
>it, then the client MUST fall back to a supported (e.g. a
>"mandatory to implement") algorithm.
>
>I use the word "MUST" intentionally, in its RFC sense.

We are talking about signatures (SIG(0) RRs) by one party to be
verified by the other.  The signing party can only sign with private
keys it has configured.  If those include multiple algorithms and it
wants to maximize the chance of success, it should have some policy
for trying them one at a time.  If no private key is available for
a mandatory algorithm, it can't use it.

The IETF certainly has the power to make its protocols such that
interoperability is possible/easy/prefered.  But if people don't want
to interoperate, I don't think "orders" from the IETF are going to
make them configure their systems interoperably.

>Right now, we are beset with attempts to control the
>client, the server, or both sides of the implementation
>of supposedly standard security protocols, sometimes in
>the face of white papers by the authors of the standards
>specifically stating the intended use of "optional" fields,
>such as we are  talking about in this specific case.

What optional fields in SIG(0)?  What white papers about SIG(0) use?
I am not aware of any...

>What is to stop a vendor from implementing a signature
>security algorithm that is proprietary and/or patented,
>and then setting up their servers to require the use of
>their signatures, thus leveraging a near monopoly in
>clients to force the use of their servers?

The US Departmet of Justice?  :-)

>Or vice-versa, what is to stop someone from implementing
>a server which understands such an algorithm, and treats
>clients which only implement the "mandatory to implement"
>algorithms as second class citizens in "their" network?

The Internet only works because people find it to their advantage to
be able to interoperate.  If, say, NSA want to use some proprietary
algorithm to secure their DNS zones and not sign them with mandatory
algorithms, that's their decision.  Most of the Internet, which does
not have this hypothetcial NSA proprietary algorithm implemented, will
treat their zones as Insecure and crackers will be able to spoof their
DNS data.  It would be their choice.

>It is not strong enough to permit optional algorithms,
>we MUST ensure that the "mandatory to implement" ones
>are universal, and that implementations which _only_
>support these CAN NOT be treated as second class network
>citizens as a result of a vendor whim.
>
>The RFC SHOULD NOT be issued until interoperability
>guarantees have been addressed in the protocol definition.

Your position does not appear to me or, apparently, to the chair to be
the working group consensus and it is inconsistent with what the IETF
has done in IPSEC and other security areas.

>-- Terry Lambert
>-- Whistle Communications, Inc., an I.B.M. Company
 >-- [email-masked]
 >-------------------------------------------------------------------
 >This is formal notice under California Assembly Bill 1629, enacted
 >9/26/98 that any UCE sent to my email address will be billed $50
 >per incident to the legally allowed maximum of $25,000.

 Donald
===================================================================
 Donald E. Eastlake 3rd                    [email-masked]
 65 Shindegan Hill Rd, RR#1                 [email-masked]
 Carmel, NY 10512 USA     +1 914-276-2668(h)    +1 508-261-5434(w)

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Terry Lambert <[email-masked]>
Date: Tue, 11 Apr 2000 12:12:52 -0700

> successively, even when multiple signatures are not allowed in one

DHCP leases work around this problem by requesting
renewal at 50% of the renewal interval.  It seems to
me that you could avoid the multiple signature need
in the key rollover case by ensuring valid overlapping
certificates were used, and making the validation
asymmetric, at the verifier, if it were really an issue.

I'd like to avoid the extra traffic, and the possibility
of political abuse of multiple signatures.

> Requiring all parties to not just implement but also
> enable and configure interoperably keys for the one or
> occasionally two mandatory algorithms has been viewed
> as unrealistic and insecure by causing excessive
> reliance on and great difficulty in changing from the
> mandatory algorithm.

Perhaps a distinction between public and private algorithms,
and a requirement that at least one public algorithm of
the vendors choice be mandatory to implement.  We would
then at least have nodding possibility o0f interoperability.

> The IETF certainly has the power to make its protocols
> such that interoperability is possible/easy/prefered.
> But if people don't want to interoperate, I don't think
> "orders" from the IETF are going to make them configure
> their systems interoperably.

Let me not mince words, then.

A vendor has implemented a non-interoperable version
of Kerberos that requires their Kerberos servers in
order to operate.

Effectively, this means that an realm authentication
server from any other manufactures, which can not
accept and act on their private interpretation of the
optional use field can not, in fact, participate as a
peer in their network.

The implications of this are that there is a leverage
of a virtual client monopoly in order to ensure that
their servers are used instead of servers from other
parties, so long as those parties do not explicitly
license code from the original vendor.

It seems to me that the looseness around the SIG(0)
ability to have multiple signatures simultaneously
aids and abets this type of practice, and that it could
therefore be easily extended to encourage/require the
use of that vendors DNS servers, as well, through a
similarly proprietary implementation.

> What optional fields in SIG(0)?  What white papers about SIG(0) use?

The optional inclusion of multiple signatures, such
that a third party client that does not understand the
proprietary signature can still achieve some minimum
interoperability, as can the vendors clients, but for
which third party servers result in broken vendor
clients.

I would argue that a single signature requirement will
prevent this: require that servers use a single signing
methodology when sending packets to particular hosts.

Allow multiple signatures only in the case where all
signatures are done using public algorithms.

Make it painful to balkanize the server space by way
of algorithm.

> The US Departmet of Justice?  :-)

That hasn't worked with Kerberos realm authentication.

It hasn't worked with RC4-based realm authentication.

> The Internet only works because people find it to their
> advantage to be able to interoperate.  If, say, NSA want
> to use some proprietary algorithm to secure their DNS
> zones and not sign them with mandatory algorithms, that's
> their decision.  Most of the Internet, which does not
> have this hypothetcial NSA proprietary algorithm implemented,
> will treat their zones as Insecure and crackers will be able
> to spoof their DNS data.  It would be their choice.

What if, instead, the NSA included their proprietary
signature, and then _also_ included a mandatory algorithm
signature?

Then the NSA could treat all zones not signed by their
proprietary algorithm as insecure, but everyone else
would treat the NSA's zones as secure.  The NSA could
then refuse to engage in peering relationships with
servers not using their algorithm.

Now say they license the use of their algorithm.

Now say that, through incompetance (e.g. key escrow), their
algorithm is found to be insufficiently secure.

Now say that there are unignorable business reasons
that you have to implement their algorithm; for the
NSA, this might be that your DNS packets can't transit
US borders, unless you implement their algorithm.

> Your position does not appear to me or, apparently, to the
> chair to be the working group consensus and it is inconsistent
> with what the IETF has done in IPSEC and other security areas.

Protocol RFCs have traditionally not been issued without
proof of interoperability between two independently
developed implementations.  Interoperability is clearly
a goal of the IETF; permitting non-interoperability by
design is a bad precedent, the proof being that this
precedent has already been abused once.

-- Terry Lambert

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 12 Apr 2000 08:22:04 +0200

At 12:12 11.04.2000 -0700, Terry Lambert wrote:
>developed implementations.

small correction: issued AS DRAFT STANDARD.
Proposed Standard docs are normally issued without proof of interoperability.

             Harald

--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]