IETF Logo Mail Archive

Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator

Roelof duToit <r@nerd.ninja> Mon, 07 May 2018 15:06 UTC

Return-Path: <r@nerd.ninja>
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 65BFF126CB6 for <tls@ietfa.amsl.com>; Mon, 7 May 2018 08:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nerd.ninja
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 Y5hFhu4bY9Qx for <tls@ietfa.amsl.com>; Mon, 7 May 2018 08:06:21 -0700 (PDT)
Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0945126CC4 for <tls@ietf.org>; Mon, 7 May 2018 08:06:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525705574; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To; l=1431; bh=twBJrM8EBb8NtG8+vlK1GZfFBjwfPJBEeXeemdJCf5A=; b=ijx/9jn9KpNWmECWDAZK+5/7Y3lE7NkOOGCbYc7JJCxkpVoi88p3qN56x1EiGFIj kCxq13p9M45kb2oTpgIHBnuTdkezkMpwOanEtJ+Sd6ZHDF/1tqOgqCU1pByzKHNVmQa Jgv7UZXf6jDWRBX646KU0CrjDl3KLdUp2sV1Fb9I=
Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525705574518923.7374743472676; Mon, 7 May 2018 08:06:14 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Roelof duToit <r@nerd.ninja>
In-Reply-To: <20180504214834.GS5742@akamai.com>
Date: Mon, 07 May 2018 11:06:10 -0400
Cc: TLS WG <tls@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja>
References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com>
To: Benjamin Kaduk <bkaduk@akamai.com>
X-Mailer: Apple Mail (2.3273)
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/TVSCjO6BP-3T6dv9INu7nxarnXA>
Subject: Re: [TLS] WGLC for draft-ietf-tls-exported-authenticator
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 07 May 2018 15:06:23 -0000

> On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> On Fri, May 04, 2018 at 11:20:55AM -0400, Roelof duToit wrote:
>> How will this (and any mechanism built on top of RFC 5705 exported key material) interoperate with middleboxes?  This use of the mechanism is not negotiated on the TLS level, so there is no extension for the middlebox to strip that would warn the endpoints not to use exported authenticators.  Are application level proxies the only compatible middleboxes?
> 
> I'm not sure I properly understand the question, in particular what kind of
> middlebox you're considering.  Note that application protocols will need to
> have some way to negotiate the use of this functionality, which presumably a
> middlebox could also inspect.


That is the problem.. some middleboxes are protocol agnostic and are used to strip the TLS layer before feeding the rest of the security stack - so called “Transport Layer Active Intercept” vs “Application Layer Intercept” (ignoring “Transport Layer Passive Intercept” for the moment).  Some middleboxes might also perform transport layer active intercept in combination with passive application detection, i.e. L7 analysis vs L7 termination.
In summary: the endpoints cannot assume that exported key material is identical in a middlebox environment.

v2.23.0 | Report a Bug | By Email