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

Roelof duToit <r@nerd.ninja> Tue, 08 May 2018 16:20 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 42BB012E891 for <tls@ietfa.amsl.com>; Tue, 8 May 2018 09:20:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sXRsS1usWBcC for <tls@ietfa.amsl.com>; Tue, 8 May 2018 09:20:24 -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 A5D8D12D967 for <tls@ietf.org>; Tue, 8 May 2018 09:20:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1525796418; s=zoho; d=nerd.ninja; i=r@nerd.ninja; h=From:Content-Type:Mime-Version:Subject:Date:References:To:In-Reply-To:Message-Id; l=7942; bh=7t2qeTPBp+VgQrHxE1Vws/J0cvIwrjbDGQ2FTwoHbl0=; b=NUQD1GLP/+VMp2iAfoIWLH/1qLdjAfYVxc3WRFo9shXt8xcvr/6OT2EliaHTDfnk 5aDGYEjAiXfaRdlmHFIIePzs/UHeOHyedSKe4UFJACvk83uy+NlhlZbSlzUW+rVHjAq 1QTk7Vv9GkBlw30M4b/Ri0B6JQ2Eg6BuZzpYkPxI=
Received: from m2657400hhtdd.lan (dynamic-acs-24-112-242-116.zoominternet.net [24.112.242.116]) by mx.zohomail.com with SMTPS id 1525796418641368.0730765794344; Tue, 8 May 2018 09:20:18 -0700 (PDT)
From: Roelof duToit <r@nerd.ninja>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F4810240-270B-4C57-AD83-FDB5F1942102"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 8 May 2018 12:20:13 -0400
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> <EFDFA96E-ED01-42AC-BA8A-7844974FDFF9@nerd.ninja>
To: Eric Rescorla <ekr@rtfm.com>, TLS WG <tls@ietf.org>
In-Reply-To: <EFDFA96E-ED01-42AC-BA8A-7844974FDFF9@nerd.ninja>
Message-Id: <726B4BF1-79AA-494E-9852-DC3682E80E3A@nerd.ninja>
X-Mailer: Apple Mail (2.3273)
X-ZohoMailClient: External
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/k497aIWEeDFMfD_qyprh0hNieu8>
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: Tue, 08 May 2018 16:20:27 -0000

I understand that there is not really anything to negotiate per se, but would it not be prudent to add a TLS extension to negotiate support for exported-authenticator in the TLS layer prior to using it in the application layer?

—Roelof

> On May 7, 2018, at 12:16 PM, Roelof duToit <r@nerd.ninja> wrote:
> 
> 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 <mailto: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>
>> 
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls