Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-00.txt

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Mon, 09 September 2019 18:59 UTC

Return-Path: <pch-b9D3CB0F5@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331681200A4 for <dnsop@ietfa.amsl.com>; Mon, 9 Sep 2019 11:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Level:
X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I95aUx-InHb7 for <dnsop@ietfa.amsl.com>; Mon, 9 Sep 2019 11:59:43 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FB0120020 for <dnsop@ietf.org>; Mon, 9 Sep 2019 11:59:42 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1i7Ot3-0000IkC; Mon, 9 Sep 2019 20:59:41 +0200
Message-Id: <m1i7Ot3-0000IkC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <156802477017.28268.17780089460480647573@ietfa.amsl.com> <86ff56cd-c936-0a81-b276-f4fd61635c7f@nlnetlabs.nl> <m1i7MJ4-0000K6C@stereo.hq.phicoh.net>
In-reply-to: Your message of "Mon, 09 Sep 2019 18:14:22 +0200 ." <m1i7MJ4-0000K6C@stereo.hq.phicoh.net>
Date: Mon, 09 Sep 2019 20:59:30 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/E2ohlhvn70QYp-kQGIwrNOXDw_M>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 18:59:44 -0000

I wrote:
>In Section 4.4, the client IP is added to the hash in the creation of the
>server cookie.

Ah, never mind, that is already in RFC 7873.

So a client that wants to (re-)use a server cookie needs to know the
source address it previously used to communicate with the server.
So if the client maintains that kind of state (and sends follow up traffic
only from the recorded source address), then the client can just as well
use a new pseudo-random client cookie each time the client creates new
state. No need to include the client IP address in the cookie or worry 
about the cookie leaking. The send off the packet will fail if the 
source address is no long available.