RE: [fw-wiz] Allowing DNS servers to operate behind NetScreen 500

From: Reckhard, Tobias (tobias.reckhard@secunet.com)
Date: 02/17/03

  • Next message: Volker Tanger: "Re: [fw-wiz] Allowing DNS servers to operate behind NetScreen 500" 
    From: "Reckhard, Tobias" <tobias.reckhard@secunet.com>
To: "'firewall-wizards@honor.ics..." <firewall-wizards@honor.icsalabs.com>
Date: Mon, 17 Feb 2003 10:18:24 +0100

    Back from the weekend, I find my post has stirred up a bit of a debate..

    Replying to both of Rob's mails in one:

    On Saturday, February 15, 2003 4:11 AM, Rob Payne wrote:
    > On Fri, Feb 14, 2003 at 08:58:41AM +0100, Reckhard, Tobias wrote:
    > > > On Thursday, February 13, 2003 3:39 AM, Rob Payne
    > > [mailto:rnspayne@the-paynes.com] wrote:
    > > >
    > > > Nothing personal to anyone, but a lot of firewalls really
    > need to get
    > > > these kinds of things right. If they do not, firewalls
    > are going to
    > > > get in the way of (DNS) security when zones start getting signed.
    > > > (Rhetorical: Has anyone attempted to fit current DNS data plus
    > > > RSA/SHA1 keys and signatures in packets 512 datagrams long?)
    > >
    > > The question is when will DNS RRs ever get signed, if at
    > all. The sheer
    > > amount of queries and number of records being requested, as
    > well as the
    > > tremendous increase in payload due to signatures appears to
    > create very
    > > real, practical problems. See
    > http://cr.yp.to/djbdns/forgery.html and
    > > http://cr.yp.to/talks/2003dnssec.pdf.
    >
    > Tobias, is that some type of bait?

    No, it is not. The reason for my response was that I don't know of any
    currently relevant reason for DNS responses to be over 512 bytes in size.
    You said that firewalls should be made to cope with such traffic, referring
    to a 'proposed standard' RFC and mentioned only DNSSEC as an example, one
    that is candidate for validity, since public/private key cryptography
    keylengths are indeed too long to fit such keys into single UDP packets.

    So I brought up the question if the example is actually valid, seeing that
    there is at least some disagreement in the DNS community on DNSSEC or,
    rather, the topic of securing DNS traffic, which in this context means
    guaranteeing the authenticity of DNS information to resolving clients.

    > DJB's ideas on the issue are quite
    > well known,

    This is where we disagree. djbdns is gaining in popularity, yes. However,
    there is a lot of disinformation and wrong quoting. I'm not able to say
    anything about which parties are responsible for how much and how harmful of
    the FUD that there is, but DJB is certainly among its victims. From what
    I've seen, his ideas are quite often not understood correctly. Therefore, I
    can't agree with your assertion that his "ideas on the issue are quite well
    known", unless "quite" can be replaced with "somewhat" or similar.

    > he thinks we should all go back to a hosts file and
    > copying it from machine to machine.

    What are you referring to here? I haven't seen any evidence of this myself.

    > Are you using ``nym-based
    > security'', currently? When are you going to start?

    No, I'm not. Need I in order to be able to discuss the topic? Have you tried
    it yourself?

    Actually, unless we implemented it ourselves, neither of us can currently
    use nym-based security, since there isn't any software that supports it.

    > Well, to get an answer on that, you might have to talk to some other
    > than DJB, who has no practical experience if he thinks you can rename
    > your machines every time you change keys. From the forgery.html page
    > you referenced, ``The idea is simply to give each computer a name that
    > includes the computer's nym, a fingerprint of the computer's public
    > key.''

    I am fully prepared to admit that I can't take a stance of my own on the
    issue yet, since I myself haven't yet delved into the topic(s) deeply
    enough. From my experience, though, I believe that DJB very much takes
    practical considerations into account, so I'm somewhat astonished at your
    words.

    > Keys need to expire, be revoked, replaced, etc. in a real world crypto
    > setting.

    Yes, this can turn into a real problem in some situations.

    > Computer names cannot change every time a key expires.

    Why not? Note that I don't mean the opposite, but you don't supply any
    reason.

    The only reason I can come up is that URLs shouldn't change as often as
    typical key expiration times necessitate. However, if I understand DJB
    correctly, his 'security information' is never inserted into URLs at all, it
    is present only on the content server. The client request is modified by the
    intermediate proxy to include the security info.

    > If
    > anyone goes with his nym-based security scheme, they will begin to
    > keep the same keys forever, thus defeating the advantage of the key in
    > the first place.

    Only if your claim that "computer names cannot change every time a key
    expires" holds true.

    > Assuming your question was not meant to be inflammatory, but that you
    > really wanted an answer, here goes.
    >
    > There are operational zones currently being signed. In fact, there
    > was a proposal at IETF 56, (11/2002 in Atlanta,) to begin signing of
    > the root zone
    > (http://www.ietf.org/internet-drafts/draft-ihren-dnsop-interim
    > -signed-root-00.txt).

    I'll check that out, thanks for the pointer (and the other one as well).

    [snip]

    > If that does not sufficiently answer your question, I would be happy
    > to provide you with any additional information that I can.

    Thanks for the offer. I may even come back to you on it.

    On Saturday, February 15, 2003 9:31 PM, Rob Payne wrote:
    [snip]
    > Are you, or more importantly is your employer, going to name systems
    > using the a public key fingerprint? If you do, what happens to the
    > credibility of the system when the name changes because a public key
    > expired and needs to be changed? How about when a system is broken
    > into and the key is compromised?

    Doesn't this danger (i.e. compromise of the private key) exist in all public
    key cryptography implementations? Surely, DNSSEC can't protect against that.

    Unfortunately I can't be sure I understand your first sentence, but I'll
    assume that you meant to say "..name systems using public key
    fingerprints?". You go on to ask what happens to a system's 'credibility'
    when its name changes due to expiration of the public key. I don't get your
    meaning entirely. What do you mean with credibility?

    The way I understood DJBs talk at Stanford, or rather the slides at
    http://cr.yp.to/talks/2003dnssec.pdf, he doesn't want to change systems'
    names as they appear to the clients of DNS proxies. He wants magic numbers,
    keys and cookies to be inserted into specific places of systems' names by
    the servers. The proxies verify the response's validity with these values.

    I'm avoiding the question of why the client should trust its proxy.. I don't
    see that question answered (nor expressed) in DJB's slides.

    > This is a security list, everyone here should be willing to
    > acknowledge that no systems are "perfectly secure." Given that, why
    > would you use security that is based upon the false assumption that a
    > key is never compromised?

    This is all based on your assumption that systems' names never change. I
    don't think it's impossible to generate new values for k, mX and r (or
    perhaps merely a subset of them) on a regular basis based on key expiration
    time. It's a process that can be fully automated and it doesn't bother the
    clients at all. Granted, you need adequate computing resources and
    sufficient entropy, which could very well be a problem with big zones.
    However, I don't see why this isn't the same with DNSSEC.

    [snip]
    > regarding DJB. Your reference to Paul Vixie is a nearly direct quote
    > from the same web pages and has absolutely no relevance. "Vixie," as
    > you call him, made that statement in reference to 2535.

    The PDF I refer to above quotes Paul Vixie from Nov. 2002, which I assume
    means the IETF meeting. FYI:

    "We are still doing basic research on what kind of data model will work for
    DNS security. After three or four times of saying ''NOW we've got this, THIS
    TIME for sure'' there's finally some humility in the picture ... ''Wonder if
    THIS'll work?''...

    It's impossible to know how many more flag days we'll have before it's safe
    to burn ROMs ... It sure isn't plain old SIG+KEY, and it sure isn't DS as
    currently specified. When will it be? We don't know. ...

    2535 is already dead and buried. There is no installed base. We're starting
    from scratch."

    > The
    > references I listed in my previous messages are aimed at replacing
    > 2535 in a way that fixes the problems that were found when
    > implementing 2535.

    I'll check them out.

    > Let's take this a step farther, so no one feels this has anything to
    > do with any DNS implementors. My point was that firewalls that block
    > fragmented UDP packets used by EDNS are getting in the way of
    > security.

    Others argue that EDNS is still fiction and that its future is undecided,
    especially when its only apparent reason for existence seems to be DNSSEC.

    > Let's ignore everything currently being done regarding
    > DNSSEC by the IETF since anything regarding DNSSEC not said by
    > Professor B. seems to be such a sensitive topic.

    Oh, I am rather unemotional about it. However, the past developments in DNS
    haven't always been optimal, to say the least, and I feel that, as long as
    we're still on square one we can and should consider all reasonable
    possibilities and choose the best. I know DJB isn't always the most pleasant
    of conversation partners, but I am of the impression that personal matters
    are influencing the IETF more than they should. Note that I am not making
    any one party responsible for this.

    > Instead let's focus
    > on any transaction that simply requires large DNS packets.

    We could, but why should we? Would that be of any more than academic value?
    I'll gladly join you, I don't mind academic discussions at all. However,
    people implementing security-critical code, such as that used to build
    firewalls, strive to reduce complexity. In doing so, they sometimes very
    intentionally implement only those parts of a protocol that they deem
    necessary. Widespread adoption is a good argument in favour of a feature
    being considered. An academic nature probably isn't.

    > For instance, a well-distributed set of name servers whose names have
    > been created using nyms. If you take 13 hosts with names based upon
    > SHA1 fingerprints, and use them as the name servers for a zone, you
    > cannot transmit that DNS message in 512 datagrams. My original point
    > still holds if the firewall blocks fragmented DNS.

    I need to investigate how secured lookups using DJB's scheme work in detail
    before I can answer this.

    > DNSSEC was an example. It is not the only reason why firewalls need
    > to do the right thing with DNS.

    Understood. I agree that DNS (and any other protocol) needs to be handled
    correctly by firewalls. However, there is not always a consensus as to what
    that means. And DNSSEC is one very prominent reason for large DNS messages
    and one that many people have misconceptions about (i.e. many people think
    it's practically there already and a purely good thing (TM), just like many
    people think BIND defines DNS). I'd be interested in other, real-world
    reasons why DNS responses should be allowed to be over 512 bytes in size.
    Not out of opposition, but out of interest.

    Cheers,
    Tobias
    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

    Relevant Pages

    • Re: [fw-wiz] DNS and Firewalls
      ... >> using nym-based security and then discussed why it is not practical. ... > DNSSEC don't solve any real-world problems. ... channel) with break the ability of those servers to communicate. ... Root server ip addresses are included in the code for some DNS ...
      (Firewall-Wizards)
    • Re: New DNS Security Paper
      ... > DNS is the most widely used protocol on the Internet yet many security ... A New Internet-Draft is available from the on-line Internet-Drafts directories. ... Although the DNS Security Extensions (DNSSEC) have been under ...
      (Pen-Test)
    • Re: Domain name on a new SBS??/
      ... AD DNS naming has very little to do with security. ... 'SBS' thing, it is pure AD and the only reason I no longer use .local, ... easily access publicly hosted websites, ...
      (microsoft.public.windows.server.sbs)
    • Re: Event ID 5719: No Windows NT or Windows 2000 Domain Controller is available for domain .
      ... In my experience what you have done with security policy should ... The workstation gets its networking information from DHCP that, ... updates DNS. ... I don't believe the problem to be at the server end though. ...
      (microsoft.public.win2000.security)
    • Re: Should DCs with DNS point to self first?
      ... > when you have all locally, by doing so IMO you're wasting server ... > good reason to do so IMO. ... there are far more issues associated with pointing a DC at itself for primary DNS than pointing at something else. ...
      (microsoft.public.windows.server.active_directory)