Re: [TLS] Concerns with draft-kinnear-tls-client-net-address

Yoav Nir <ynir.ietf@gmail.com> Mon, 25 March 2019 18:31 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17CBB1206B4; Mon, 25 Mar 2019 11:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tqFVySAqwgkk; Mon, 25 Mar 2019 11:31:29 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 740C61206D6; Mon, 25 Mar 2019 11:31:28 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id t5so11336646wri.7; Mon, 25 Mar 2019 11:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KKS8rROW9yniKrWeRzuFqVde0RgfbTXjG8QG+xN5v9I=; b=sLD2HsHeGCQk1DXE7xXFg4S2JotCFUB/QemzyUglQHUimutDLLv1EjkHn7ix1rWK83 ZH9NLvQqUzif2l/Dpi1PIzdfhDK7xFJk1i+hmEwYAbi10bWm6lox8wmp1I9ZWJ+k44lD 9aWuPlS4v9RxxRQozaSYwS+0i+7yzZzTlHATCi26qe+L9g1ev5Fmp3Xzq0Wq+bkJxove l3p02Ph/TcO0eJQXnuMY/wyDkP1q2CJvu1Kin9+oMTOSFuF4CfTm4Ej0F96QyPfYkqHP S3v10aZaQzQl5kx6/KaFi0ltKJfsI5PU4gERhkEm/KgcTZSJIwhzCHbqEugv0ofF0HhX AWaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KKS8rROW9yniKrWeRzuFqVde0RgfbTXjG8QG+xN5v9I=; b=Cqs9SvS6zmTeMKfZ9+kxiSyIsBJu/BO3BPe1Owf1KXe5hpmfBxNivzxEbnsMNJqdAg OjKB/Pyi7VQxbNDqLMs5eoF4fB5Qy+q276AkzCByOKzoOhAp+uFjM6jI8ei28t9Lv1ax +Kr4jBVWdZ+XBrFzfyDPKGdyCQwuWSrb51RK2kwbjCkX06+eIF7bYvH0vOtZn1hCOEvK sMhVFJkIl33BoFnDgJMgEbsfHgaUQtJWHrTriMWPEpKvu7VXZSseyffg8+kGsgMvhsHG 5wf80GL+Uad/7wUCQV8h2Eaxiizz6iX1WyXcJOOXipYC/qiRH9XpSkdELknRnGlR6f1N 4OmQ==
X-Gm-Message-State: APjAAAVQbOfO78Z7EeAZuTJLtXAaoknEgOcHuW6c9oL6gVFwszrDZ6vT bTlRO81h7quxz0F1RAHDS/k=
X-Google-Smtp-Source: APXvYqyfETm5eGch5DeodfU1hlCmWeQMJjxJpq79O3Irgl3Z36d1s0mp72nx9Sp6uhHvibrPUrPubw==
X-Received: by 2002:a5d:53c1:: with SMTP id a1mr10188711wrw.174.1553538686931; Mon, 25 Mar 2019 11:31:26 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:fcc0:b785:153b:fe6c? ([2001:67c:1232:144:fcc0:b785:153b:fe6c]) by smtp.gmail.com with ESMTPSA id c20sm20324426wre.28.2019.03.25.11.31.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 11:31:25 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <890AF854-FE00-45D6-81C6-95A09393AEFF@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9034EC0B-A429-48A1-8BBE-2FB23D671FEC"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 25 Mar 2019 19:31:24 +0100
In-Reply-To: <1755991.yLsQ4jojd4@pintsize.usersys.redhat.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, David Schinazi <dschinazi.ietf@gmail.com>, draft-kinnear-tls-client-net-address@ietf.org
To: Hubert Kario <hkario@redhat.com>
References: <CAPDSy+4brMwvwWp0zMb4SYqOFC5jtk=R1uKB4jKPD+Han36Hbg@mail.gmail.com> <EC983D53-3E2B-4B6E-B657-8CDA158812C9@gmail.com> <1755991.yLsQ4jojd4@pintsize.usersys.redhat.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/G-sitdQaR17AbMfEORAITOXmTBM>
Subject: Re: [TLS] Concerns with draft-kinnear-tls-client-net-address
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Mar 2019 18:31:31 -0000


> On 25 Mar 2019, at 19:23, Hubert Kario <hkario@redhat.com> wrote:
> 
> On Monday, 25 March 2019 14:58:29 CET Yoav Nir wrote:
>> Yeah, so this looks very much like the IKE mechanism (the draft even says
>> so)
>> 
>> In IKE the reason for this is to detect NAT because IPsec does not traverse
>> NAT. We need to detect the NAT so as to choose an IPsec variant that
>> traverses NAT.  If the server (or IKE Responder) lies, you might use the
>> NAT Traversing method when it’s not required, or if the server is really
>> good at lying, you might not use NAT Traversal when you should.
>> 
>> With the proposed TLS extension, I would like to see a better analysis for
>> what happens if the server lies.  What happens if the client uses the
>> answer to do geolocation?  We can easily take this to a “gay kid in Uganda”
>> scenario.
>> 
>> But I think the more interesting question is why do it at this layer?  Why
>> not use some web service such as the API version of
>> https://www.whatismyip.com <https://www.whatismyip.com/> <https://www.whatismyip.com/ <https://www.whatismyip.com/>> ?  The answer is a
>> property of the device, not to the socket.  We might as well have the
>> device figure this out.
> 
> how is it property of device? at best, it's a property of a LAN. And a LAN may 
> have multiple Internet uplinks, every other connection may end up with a 
> different IP (albeit from a small pool), so a public IP of any particular 
> connection does not reliably indicate public IP of subsequent connections.

It’s perhaps a property of the device at the current connection configuration. Pretty much any consumer device will have a preferred network where the default route is. Any phone with a metered and a non-metered connection will prefer the non-metered connection, and PCs will use the link where the default route is.  It is a reasonable approximation to assume that the web service connection to whatismyip will follow the same path as your other TLS connection. 

Servers may have more complicated routing tables, where the “regular” TLS connection might be using a dedicated link while the connection to whatismyip is going to the “Internet”.  I don’t think this is the scenario that this draft is working on.

An interesting twist even for consumer devices may be where one of the two connections chooses IPv4 while the other chooses IPv6.  In that case, they might end up on different links if, for example, the metered connection offers IPv6 while the non-metered connection does not, or vice versa.

Yoav