Re: [Ice] TLS Candidates

Bernard Aboba <bernard.aboba@gmail.com> Fri, 17 February 2017 21:46 UTC

Return-Path: <bernard.aboba@gmail.com>
X-Original-To: ice@ietfa.amsl.com
Delivered-To: ice@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4433129BF1 for <ice@ietfa.amsl.com>; Fri, 17 Feb 2017 13:46:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7, 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 HDTAWv_t-6K7 for <ice@ietfa.amsl.com>; Fri, 17 Feb 2017 13:46:50 -0800 (PST)
Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (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 7E1C6129BF4 for <ice@ietf.org>; Fri, 17 Feb 2017 13:46:50 -0800 (PST)
Received: by mail-vk0-x22b.google.com with SMTP id t8so36704814vke.3 for <ice@ietf.org>; Fri, 17 Feb 2017 13:46:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=aAw18ui3Q91SFA9FOXz9f4C6S9djvXR5n90ZIGfasVs=; b=NYiDWE9eW699ZFvB6r+2vn5IHFTuKH38jK9WbnOI2yVhGhDLyOWqlzEsXK4fSNRdnV ExXBdlszd+ALAWP0COyDs7MrokiXf3ZEBraTknZPiqO19vp09AubmUC/QYmvLXP6dgyl KvtvKNNKjYV48N5aV7qiwTf7PwoKuq5dkfD6VJ+iJ5NsAyOtCtRK2pgXkTfwJ/hInVfR /pvxkwNlmXtvLi8S6dkfCWciyTbVBItdX5DeY/fxooOiQ2KVQF0HFwO9Nfa1hLQiMbiC T8iR83k8Yluat81Aj41wNylhLY1WzYKCIEQNryhtHJwvKMasGCEJ75WovT8E1qX1YeRe b19Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aAw18ui3Q91SFA9FOXz9f4C6S9djvXR5n90ZIGfasVs=; b=dQSIvQ+J2HLphpS6rTnDRE8+9ZkSnZfdmJBgnL4tURnEDMOMn7PLSFsz1/+i+2ER4H HYlsdy87S4XH7cTXttuprJtqPdbmbIfxIznnJAJtx+mSdkJPpe9kAcKWKrFJc20KAoiR qXmc90cRnVEmSNNn1jttQmzzBFKiSDgkMDEUzChSNKdb9Q6ZDhSiQdJGOdz2axEX+ftG SV0q1jEenhc1eqxn5bZHIQb0sePRpNut6iWg4BrW6Xw54vmizFJf6yqE9SNcZe/+oC3H LlBa+fY3JqkerySKa7GnIuMDw1NKnzFyIpr6Riy7Ni4pU79Cks8rN6gSxJbhAsN1cGhq 4/og==
X-Gm-Message-State: AMke39kwBiGsWeS3wBlmnyrfMxRR8qQk+o1CjY/fEnP/WGJ++8Uo1d3AcASngKke8rPBUn2W7OfBEfTmCI4riQ==
X-Received: by 10.31.227.193 with SMTP id a184mr4984111vkh.106.1487368009162; Fri, 17 Feb 2017 13:46:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.88.90 with HTTP; Fri, 17 Feb 2017 13:46:28 -0800 (PST)
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Fri, 17 Feb 2017 13:46:28 -0800
Message-ID: <CAOW+2dsOMSX-Sv_6_TPgEvg4QUpG+xRkrej64-NdRq4Ac80uMw@mail.gmail.com>
To: ice@ietf.org
Content-Type: multipart/alternative; boundary="001a114df80ad627c40548c0d93a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ice/B5Xc2s00Ol6EQJbw7o5NG9uPMpk>
Subject: Re: [Ice] TLS Candidates
X-BeenThere: ice@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interactive Connectivity Establishment \(ICE\)" <ice.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ice>, <mailto:ice-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ice/>
List-Post: <mailto:ice@ietf.org>
List-Help: <mailto:ice-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ice>, <mailto:ice-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2017 21:46:52 -0000

Roman said:


"We have encountered a few large corporate installations that only allowed
TLS connections to port 443."

[BA] We have also encountered these deployments, and initially
implemented a "fake" TLS handshake along the lines that Peter
describes. However, we found that some customers had installed deep
packet inspection boxes that could tell the difference between a
"fake" TLS handshake and a real one. So having a standardized way to
do TLS candidates would be a good idea.

On Tue, Jan 24, 2017 at 4:21 PM, Peter Thatcher <pthatcher@google.com>
wrote:

> Our implementation of ICE has a type of candidate called "SSLTCP" which
> does a fake TLS handshake to get through firewalls that only allow TLS
> connections.  We've been using it for years.  And I'm guessing some of our
> web products would appreciate that being in other browsers as well, so we
> may be interested in seeing it as part of the standard (or a less fake
> version of it).  But I don't have any stats about how often those work but
> normal TCP candidates don't, so I can't say for sure how useful it really
> is.