Re: [TLS] TLS and middleboxes again

Yoav Nir <ynir@checkpoint.com> Fri, 26 August 2011 20:26 UTC

Return-Path: <ynir@checkpoint.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 3EC5821F8C9D for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 13:26:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.36
X-Spam-Level:
X-Spam-Status: No, score=-10.36 tagged_above=-999 required=5 tests=[AWL=0.239, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vT+q-81BrnR0 for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 13:26:41 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 65FDE21F8C99 for <tls@ietf.org>; Fri, 26 Aug 2011 13:26:41 -0700 (PDT)
X-CheckPoint: {4E580F1C-0-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p7QKRsie030530; Fri, 26 Aug 2011 23:27:54 +0300
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Fri, 26 Aug 2011 23:27:54 +0300
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 26 Aug 2011 23:27:54 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Yaron Sheffer <yaronf.ietf@gmail.com>
Date: Fri, 26 Aug 2011 23:27:52 +0300
Thread-Topic: [TLS] TLS and middleboxes again
Thread-Index: AcxkLqJFWF+j9ptiQTGecxQFg9JpjA==
Message-ID: <485D9A10-318C-4202-B171-D3C2BC5FA3DB@checkpoint.com>
References: <mailman.69.1314385218.21832.tls@ietf.org> <4E57FC4B.3080809@gmail.com>
In-Reply-To: <4E57FC4B.3080809@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS and middleboxes again
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Fri, 26 Aug 2011 20:26:42 -0000

On Aug 26, 2011, at 11:04 PM, Yaron Sheffer wrote:

> Hi Uri,
> 
> two reasons for the middlebox to use the MAC (which may or may not be 
> "justifiable" to you) are:
> 
> - Many security applications add a textual signature similar to "This 
> mail was scanned by The Best Antivirus".
> - If something bad is detected in the traffic, the middlebox might want 
> to issue an HTTP redirect, e.g. to display a copy of the company's 
> security policy.
> 
> And I like Nikos' idea of having a different MAC for middlebox-generated 
> traffic. Although sharing the middlebox-specific MAC with the individual 
> middlebox AND with the server, while not sharing it with other 
> middleboxes along the path (yes the draft assumes there could be 
> several) would be a challenge.

Only if you require the other middleboxes to verify the MAC. If the MAC for the middlebox is derived from the master secret (for example, with an extractor), the server can automatically calculate it. But once you've begun to make changes, you likely have to re-MAC all subsequent records, because it's likely that the modified content takes a different amount of records, and then the sequence number count is off.