Subject: DNSEXT WG Last Call: SIG(0)

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 03 Mar 2000 13:33:36 -0500

This is a last call on this document, SIG(0) updates RFC2535 in 
the definition of transaction signatures. The changes are mostly 
to make SIG(0) more like TSIG in implementation and result of 
implementation experience. 
SIG(0) is required for TKEY exchange when no existing shared secret
between two DNS entities exist. 

This is a WG last call ending March 20'th 2000. 

A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-sig-zero-00.txt

This draft is on standards track, if you disagree with that please state why
in your response. 

        Olafur

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

---

From: Brian Wellington <[email-masked]>
Date: Tue, 7 Mar 2000 15:39:27 -0500 (EST)

> between two DNS entities exist. 

Once again, I suggest that the number of SIG(0) signatures per message be
restricted to 1.  Allowing more than one introduces unnecessary
complexity.  The only benefit would be to allow TKEY-generated TSIGs to
have multiple authorizations (derived from each signing SIG(0)), but the
necessity of this feature is unconvincing.  Also, multiple authorizations
can lead to conflicts whose resolution is not specified in any document.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Tue, 07 Mar 2000 22:49:21 -0500

Actually, although multiple different authorization was the only
reason I mentioned when we last talked about this, there is another.

With TSIG, you have (or at least believe you have) a shared (secret)
key and algorithm.  With SIG(0), you typically don't have or need that
since the public key to verify the signature can be obtained from the
DNS.  However, that also means you don't know what algorithm(s) the
server understands.  So you might want to have, for example, two
signatures giving exactly the same authorization but with diffeent
algorithms and the understanding would be that if any SIG(0) for that
specific authorization verified, you have the authority indicated
(assuming it conforms to server policy, etc.).  I suppose it could
also be possible that during some key rollover situation with some
clock jitter, you might want two signatures with the same authority
and algorithm but different keys, although usually you would arrange
for the key validities to overlap enough that it wouldn't be a
problem.

Donald

From:  Brian Wellington <[email-masked]>
Date:  Tue, 7 Mar 2000 15:39:27 -0500 (EST)
To:  Olafur Gudmundsson <[email-masked]>
cc:  [email-masked]
In-Reply-To:  <[email-masked]>
Message-ID:  <[email-masked]>

---

From: Edward Lewis <[email-masked]>
Date: Wed, 8 Mar 2000 09:01:13 -0500

I agree with Brian.  If we start with one signature and, given operational
experience demanding multiple signatures, later expand the protocol to
allow multiple we will be better off that with the alternative.

If we start with multiple but decide single is the way to go, then we will
have deployed resolvers that won't interoperate with new servers.

Given the choice between a restrictive system (one sig) and a more flexible
system (multi sigs), the more restrictive will be more secure in an
operational setting.  I don't care if "theoretically" multi sigs are as
safe as single sigs, once we get into operations, if a critical assumptions
supporting the proof is voided, the proof is useless.[1]

>reason I mentioned when we last talked about this, there is another.
...
>>restricted to 1.  Allowing more than one introduces unnecessary

[1] Gratuitous analogy - there was once a race between a Porsche and a
Chevy.  Although standing still the Prosche was a faster vehicle and the
course was thought to favor it, the Chevy won.  The reason turned out to be
Chevy's lack of aerodynamic styling.  The (paved) road course was somewhat
uneven (few potholes, other depressions), leaving small pockets of vaccuum
as the Porsche rushed by.  The Chevy didn't have the vaccuum problems since
it didn't hug the road.  The moral is - the Porsche assumed a flat surface,
but in the real world, the road settles.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"Trying is the first step to failure." - Homer Simpson
"No! Try not. Do... or do not. There is no try." - Yoda
"It takes years of training to know when to do nothing" - Dogbert 1/21/00

Opinions expressed are property of my evil twin, not my employer.

---

From: Brian Wellington <[email-masked]>
Date: Wed, 8 Mar 2000 10:23:09 -0500 (EST)

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

> server understands.

I'm not sure about this.  The server is expected to understand the
mandatory to implement algorithms,  I think a better solution is to allow
the server to notify the client that a SIG(0) could not be verified, and
then the client would never try it again.

The client can also query the server and determine what keys it uses for
SIG(0) (or at least an approximation - all dnssec protocol host keys at
the server's name), and determine what algorithms it understands from
that.

> So you might want to have, for example, two
> (assuming it conforms to server policy, etc.).

But if the client sends 2 SIG(0)'s with one message, and the server
verifies one of them, the client doesn't know which one was verified.  So,
any further SIG(0) signed messages will also need to be signed with both.

I'd recommend something the following:
	- client sends RSA SIG(0) signed TKEY mesage
	- server doesn't do RSA, sends back NOTAUTH
	- client sends DSA SIG(0) signed TKEY mesage
	- server sends back signed TKEY response, all is good.

Of course, the client should probably send DSA first, since it's
mandatory, but that wouldn't illustrate the point.

> I suppose it could

This could be a problem, but I think that it should be up to the user to
properly configure keys.

Brian

---

From: "Donald E. Eastlake 3rd" <[email-masked]>
Date: Wed, 08 Mar 2000 11:05:49 -0500

I don't see how permitting multiple signatures for the same authority
but different algorithms, such that the request is considered valid if
any of them verify, reduces security, since you can just send N
requests, each with one of the multiple signatures.  However, since
you can do that, it is also not particularly important to allow
multiple signatures for this reason.

Donald

---

From: Terry Lambert <[email-masked]>
Date: Wed, 08 Mar 2000 09:31:29 -0800

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

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

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.

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.

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

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?

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.

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