IETF Logo Mail Archive

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

Roelof duToit <r@nerd.ninja> Mon, 07 May 2018 16:16 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 B31FA126DFF for <tls@ietfa.amsl.com>; Mon, 7 May 2018 09:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (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 DldLMtT8yRnC for <tls@ietfa.amsl.com>; Mon, 7 May 2018 09:16:41 -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 50C13120726 for <tls@ietf.org>; Mon, 7 May 2018 09:16:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525709797; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References; l=6286; bh=6j7Nrg2Ys+n11sbzIHxXJFglijCz4INIIhxpSc/tgns=; b=qeWdxMNMYTQMG/Xacm25GoneeDIzGtOUPeW+VOaGjgr6/XwPyIDKSJa6yWgDAzUj 3EnBpxO8/T0SNSyF8+FEUSxC1Z3N9CXyQfExz5b/LKvwiWYlMubHhWXB2vP3QFay7t7 uVs0Ueo8SFQErA0jAIHPwSNIEF4oeDAX4AvBR4pA=
Received: from [192.168.14.195] (66.37.54.70.nauticom.net [66.37.54.70]) by mx.zohomail.com with SMTPS id 1525709797347959.4615496468837; Mon, 7 May 2018 09:16:37 -0700 (PDT)
From: Roelof duToit <r@nerd.ninja>
Message-Id: <EFDFA96E-ED01-42AC-BA8A-7844974FDFF9@nerd.ninja>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F29301-4C96-4A67-96BA-D73F3C390296"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 07 May 2018 12:16:30 -0400
In-Reply-To: <CABcZeBPp_ibhmKJfLvqGMJj4sz6u4bC1-2ncJZ3zbGVCyEHCPw@mail.gmail.com>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, TLS WG <tls@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <4E347898-C787-468C-8514-30564D059378@sn3rd.com> <96B30D45-BAA9-4798-B222-F7890157A434@nerd.ninja> <20180504214834.GS5742@akamai.com> <50E87E1B-A2DE-4E0A-B851-B83D2AA9320D@nerd.ninja> <CABcZeBPp_ibhmKJfLvqGMJj4sz6u4bC1-2ncJZ3zbGVCyEHCPw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YocG1AFeBuJaO-WthUipR4ZEYRk>
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 16:16:43 -0000

Agree.  Middleboxes can signal on the TLS layer that token-binding is not supported, but not for exported-authenticator.

> On May 7, 2018, at 12:06 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> Note that this is different from Token Binding because that's negotiated by an extension, so per S 9.3, non-supporting middleboxes need to strip out the extension
> 
> -Ekr
> 
> 
> On Mon, May 7, 2018 at 8:06 AM, Roelof duToit <r@nerd.ninja <mailto:r@nerd.ninja>> wrote:
> 
> > On May 4, 2018, at 5:48 PM, Benjamin Kaduk <bkaduk@akamai.com <mailto: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.
> 
> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

v2.23.0 | Report a Bug | By Email