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

Philip Homburg <pch-dnsop-4@u-1.phicoh.com> Wed, 06 November 2019 16:27 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 ABE891208B2 for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2019 08:27:54 -0800 (PST)
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 oJIvnnm3OTmV for <dnsop@ietfa.amsl.com>; Wed, 6 Nov 2019 08:27:53 -0800 (PST)
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 320FC1208AE for <dnsop@ietf.org>; Wed, 6 Nov 2019 08:27:53 -0800 (PST)
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 m1iSO9v-0000LaC; Wed, 6 Nov 2019 17:27:51 +0100
Message-Id: <m1iSO9v-0000LaC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Willem Toorop <willem@nlnetlabs.nl>
From: Philip Homburg <pch-dnsop-4@u-1.phicoh.com>
Sender: pch-b9D3CB0F5@u-1.phicoh.com
References: <157290108089.13928.16346384980882076091@ietfa.amsl.com> <4479f132-c558-85d2-40d3-793fe1d52b52@nlnetlabs.nl>
In-reply-to: Your message of "Wed, 6 Nov 2019 16:26:18 +0100 ." <4479f132-c558-85d2-40d3-793fe1d52b52@nlnetlabs.nl>
Date: Wed, 06 Nov 2019 17:27:50 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IdQdC-fkpvYEejY2ERB_8Tryubs>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.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: Wed, 06 Nov 2019 16:27:55 -0000

>Philip Homburg pointed out that, although impractical to determine the
>Client IP before Client Cookie construction, it is feasible for a Client
>to detect it when it learns a Server Cookie from a specific Server.  It
>can subsequently be tried to be reused for the same Server which will
>fail if the Client IP has changed.
>
>This new (and practically implementable) requirement does not only
>enhance privacy and make DNS Cookies work with the IPv6 Privacy
>Extensions (by preventing tracking), it also makes them work in other
>environments where Client source IP can change frequently, such as in
>setups with multiple outgoing gateways.

Note that my preference was a pseudo-random client cookie. 

I can see two issues with the current approach:
1) I'm not sure this actually fixes the IPv6 privacy extensions problem.
   The same client cookie can be used on different addresses if the 
   server doesn't support cookies and the client at some point forgets
   that the server doesn't support cookies (and sends the server the
   same client cookie after a new privacy address is generated).

2) As an extension of the previous, if no server supports cookies, then the
   client will not change the Client Secret and continues to use the same
   client cookie after it moves to new location.