IETF Logo Mail Archive

Re: [TLS] TLS and middleboxes again

"Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu> Fri, 26 August 2011 16:10 UTC

Return-Path: <prvs=7219dbd7e4=uri@ll.mit.edu>
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 8BF5F21F85A1 for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 09:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.398
X-Spam-Level:
X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 pGWJ0Vu8aP2T for <tls@ietfa.amsl.com>; Fri, 26 Aug 2011 09:10:56 -0700 (PDT)
Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8921F850E for <tls@ietf.org>; Fri, 26 Aug 2011 09:10:51 -0700 (PDT)
Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id p7QGBjYn018055; Fri, 26 Aug 2011 12:11:45 -0400
From: "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
To: "'nmav@gnutls.org'" <nmav@gnutls.org>, "'juhovh@iki.fi'" <juhovh@iki.fi>
Date: Fri, 26 Aug 2011 12:11:44 -0400
Thread-Topic: [TLS] TLS and middleboxes again
Thread-Index: AcxkB8AbP0+DJMznS4mpjOUeIO7yCwAAxltb
In-Reply-To: <4E57BDCF.7050307@gnutls.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-08-26_05:2011-08-26, 2011-08-26, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=6 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1012030000 definitions=main-1108260141
Message-Id: <20110826161051.85A8921F850E@ietfa.amsl.com>
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 16:10:56 -0000

There COULD be justifiable need to observe the traffic and thus to share the encryption key. At this time I see _no_ justifiable need to modify the traffic and thus believe that the MAC key must not be shared with the third parties. 

If there's something wrong with the content - force the connection to close/abort.
 
--
Regards,
Uri

----- Original Message -----
From: Nikos Mavrogiannopoulos [mailto:nmav@gnutls.org]
Sent: Friday, August 26, 2011 11:37 AM
To: Juho Vähä-Herttua <juhovh@iki.fi>
Cc: tls@ietf.org <tls@ietf.org>
Subject: Re: [TLS] TLS and middleboxes again

On 08/26/2011 12:53 PM, Juho Vähä-Herttua wrote:

>> A few comments:
>> - On top of the encryption keys, we probably need to support sending
>> the MAC keys. Subject to client and server policy of course.
> I have no reason to support sending the MAC keys, and letting the proxy
> to modify the actual contents of the connection sounds a bit scary to
> me... What's the actual use case for this? I'm sure there's some, but I
> can't think of anything sensible right now. Basically sharing the MAC
> keys would make it similar with the certificate MitM attack currently used.

Or maybe a different MAC key is provided to the middle box, which will
use this to rewrite a MAC message (and tag it with a different
content-type such as modified-record).

That way the client will know whether the packet received is original
or modified.


regards,
Nikos
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email