Re: [TLS] TLS and middleboxes again

Michael D'Errico <mike-list@pobox.com> Sat, 27 August 2011 00:38 UTC

DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :content-type:content-transfer-encoding:date:from:to:subject :in-reply-to:references:message-id; q=dns; s=sasl; b=lF7eHBwjzRO gHuJkQU+wqhx+01l5uvV0qSCab1Kwk4loRfGnfzPLCWcx2ZL2TqY8PoXX6Se2ZnH Mk8Y1NviBKA1K0BW2Rx3dpqPprBDEccMTdz0tgULapeLaiMSvy9KE+BP4jhVuUpj uai9ynDCwvOGEh+Wr+ytPoBB5eX/homQ=
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 26 Aug 2011 20:38:35 -0400
From: Michael D'Errico <mike-list@pobox.com>
To: tls@ietf.org
In-Reply-To: <20110826235446.421CC21F8AF4@ietfa.amsl.com>
References: <20110826235446.421CC21F8AF4@ietfa.amsl.com>
Message-ID: <2772e055daa79988a4fa890a198e4c52@pobox.com>
User-Agent: RoundCube Webmail/0.3-RC1
Subject: Re: [TLS] TLS and middleboxes again
Precedence: list

I'm also against allowing a middlebox to modify anything 
(undetectably).
Any spec that allowed that could not legitimately be called a TLS
"extension" but rather a "subversion".

Mike



On Fri, 26 Aug 2011 19:55:53 -0400, Blumenthal, Uri - 0668 - MITLL 
wrote:
> I agree with Daniel.
>
> --
> Regards,
> Uri
>
> ----- Original Message -----
> From: Daniel Kahn Gillmor [mailto:dkg@fifthhorseman.net]
> Sent: Friday, August 26, 2011 04:45 PM
> To: tls@ietf.org <tls@ietf.org>
> Subject: Re: [TLS] TLS and middleboxes again
>
> On 08/26/2011 04:04 PM, Yaron Sheffer wrote:
>> 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".
>
> Just to be clear, this approach has no security value unless they 
> also
> actively filter *out* any and all content which might be rendered as
> "This mail was scanned by The Best Antivirus".  Otherwise, it's 
> trivial
> for an attacker to include the string in their initial mail.
>
> And frankly, with HTML e-mail these days, i suspect it would be 
> rather
> difficult to match all strings that might render to something 
> visually
> indistinguishable from this.  and difficult to excise them cleanly
> without damaging other content.  Once an antivirus starts actively
> tampering with content, i think it's beyond its useful scope, 
> regardless
> of the TLS implementations.  Keep the communication channels 
> separate,
> thanks.
>
>> - 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.
>
> Since HTTP redirects can only be done in an HTTP header, the 
> middlebox
> would need to buffer all HTTP content before relaying it to the User
> Agent, in case "bad" material was found at the end.
>
> I don't think either of these use cases are valuable, certainly not
> valuable enough to warrant allowing middleboxes to violate the 
> integrity
> guarantees of TLS.
>
> 	--dkg

Re: [TLS] TLS and middleboxes again Michael D'Errico
[TLS] TLS and middleboxes again Yoav Nir
Re: [TLS] TLS and middleboxes again Yaron Sheffer
Re: [TLS] TLS and middleboxes again Juho Vähä-Herttua
Re: [TLS] TLS and middleboxes again Nikos Mavrogiannopoulos
Re: [TLS] TLS and middleboxes again Blumenthal, Uri - 0668 - MITLL
Re: [TLS] TLS and middleboxes again Yaron Sheffer
Re: [TLS] TLS and middleboxes again Yoav Nir
Re: [TLS] TLS and middleboxes again Yoav Nir
Re: [TLS] TLS and middleboxes again Daniel Kahn Gillmor
Re: [TLS] TLS and middleboxes again Blumenthal, Uri - 0668 - MITLL
Re: [TLS] TLS and middleboxes again Chris Richardson
Re: [TLS] TLS and middleboxes again Yoav Nir
Re: [TLS] TLS and middleboxes again Yaron Sheffer
Re: [TLS] TLS and middleboxes again Yoav Nir
Re: [TLS] TLS and middleboxes again Yaron Sheffer
Re: [TLS] TLS and middleboxes again Philip Gladstone