Re: [TLS] Concerns with draft-kinnear-tls-client-net-address
Yoav Nir <ynir.ietf@gmail.com> Mon, 25 March 2019 13:58 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 05492120381; Mon, 25 Mar 2019 06:58:36 -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 Cnthnr028gdB; Mon, 25 Mar 2019 06:58:33 -0700 (PDT)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 54F431203EF; Mon, 25 Mar 2019 06:58:33 -0700 (PDT)
Received: by mail-wm1-x32d.google.com with SMTP id 4so9044756wmf.1; Mon, 25 Mar 2019 06:58:33 -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=fPleZQ3o8ZBw2rz4xbKjVdk1QoWggP/KyBKB2jObdrk=; b=Jtr9L2mIdyN++FwVkNtDhiKzDVHB7sdl0RQ5odE7HKhNn39TFfjVsOwE9Rg4ufIqjQ calkYLUOwF97gcuX6rODyg52zO47uocc6FOrsGknG81vgQtQzQ9kHI7m6YExSeq5CYY8 GxJFQkFIgbwL7VuBlcdNkg8CZZLPFdOK4J8d7vVwkIYFCzmye56yoEeLmQs+Zh0fbY6R 1ZnPPR+k3VfsiScqxVA850Z3n5/RPzkBenyI/GFQHFuOBA1ytzKoDF1wEQcTWZ17EfAi N2jDiNLyfQmOKsZ2bsSt33+eF8g0DIM07UVqRSnfbThTxl+9H7kOVWH4gNiLlcWICIZg v3cQ==
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=fPleZQ3o8ZBw2rz4xbKjVdk1QoWggP/KyBKB2jObdrk=; b=iHpjnbUrW3IYmREN+FX39oNh0tx0N4ZNdZ6xJ/1k67TxO2xCGuKmYe9B08LybUwS3w du/s+oANARLJ47kewtUBRL4LcoAJZebpZfj1yXcywTfWJ5VXtuBcrjeGkfARujH1nTqj GgRRUkF6fyZrT8pR5F5gvvfccw4lv2/h3SF+Mg043wWwuaXtjk+IAgmYjLlbVv6ct7MP RgbCQuV2oVqnJOS68DRUD/DBRI8Y3ER3l4MPwehz/n+K80FHi+yV+1bQke4Hb7W/o0/9 aNGmlfSgAcSeovQ03zCinuQN4dDvVVFlzf8p0unbmjI3HuRQjedH4M/lX+P8pCHMlpZj 5wzg==
X-Gm-Message-State: APjAAAW3IwxcSMZz+k1V/nimlE6rxCRmyM9TR3xI9eJxWhaeHdCdoEhi 5YhsM9QTbL+on50h/SYqSNYVmYZGjAM=
X-Google-Smtp-Source: APXvYqzVJmJO3n6/gV4RjnNDbBSkbEd8//KGDRjOetSeAvNe8SfE7k9ULN0ecu9W8K6yA41uM3eQvg==
X-Received: by 2002:a1c:f00a:: with SMTP id a10mr12500747wmb.100.1553522311904; Mon, 25 Mar 2019 06:58:31 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:113b:478f:7289:5cb? ([2001:67c:370:128:113b:478f:7289:5cb]) by smtp.gmail.com with ESMTPSA id v6sm23890311wme.24.2019.03.25.06.58.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Mar 2019 06:58:31 -0700 (PDT)
From: Yoav Nir <ynir.ietf@gmail.com>
Message-Id: <EC983D53-3E2B-4B6E-B657-8CDA158812C9@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_50892020-E362-4F4A-AAB1-E089F71FDD00"
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Mon, 25 Mar 2019 14:58:29 +0100
In-Reply-To: <CAPDSy+4brMwvwWp0zMb4SYqOFC5jtk=R1uKB4jKPD+Han36Hbg@mail.gmail.com>
Cc: draft-kinnear-tls-client-net-address@ietf.org, tls@ietf.org
To: David Schinazi <dschinazi.ietf@gmail.com>
References: <CAPDSy+4brMwvwWp0zMb4SYqOFC5jtk=R1uKB4jKPD+Han36Hbg@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/jHDcYTy4L1CSrSAY2BOOAOQpVLs>
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 13:58:36 -0000
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/> ? The answer is a property of the device, not to the socket. We might as well have the device figure this out. Yoav > On 25 Mar 2019, at 12:24, David Schinazi <dschinazi.ietf@gmail.com> wrote: > > Hi Tommy, thanks for the presentation. > > I do not think the draft succeeds at addressing its goals. The mechanism is a fine way for the client to receive its public address (assuming the server is honest) but I can't see anything useful the client can do with that information. > > 1) Keepalives > The client cannot adjust its keep alive timeouts based on this information because the network could contain stateful firewalls that require keepalives similar to NATs but are not detectable this way because they do not change addresses. > > 2) Unique Identifiers > The presence of a NAT does not provide client privacy guarantees. It is trivial for network operators to deploy NATs that still allows 1-to-1 mapping of public address+port to private address+port. The most common example is NPT66. Therefore you cannot use this information to decide whether to reuse DoT connections. > > 3) ASN > If the goal is for the client to find its ASN, you might as well build a mechanism for the server to send the ASN to the client instead of its address. Otherwise you will need to save the entire database of address-to-ASN mappings on all clients which isn't feasible on smartphones. > > Thanks, > David > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [TLS] Concerns with draft-kinnear-tls-client-net-… David Schinazi
- Re: [TLS] Concerns with draft-kinnear-tls-client-… Yoav Nir
- Re: [TLS] Concerns with draft-kinnear-tls-client-… Hubert Kario
- Re: [TLS] Concerns with draft-kinnear-tls-client-… Yoav Nir
- Re: [TLS] Concerns with draft-kinnear-tls-client-… Hubert Kario
- Re: [TLS] Concerns with draft-kinnear-tls-client-… Yoav Nir