Subject: Re: [TLS] TLS and middleboxes again

From: Yaron Sheffer <[email-masked]>
Date: Fri, 26 Aug 2011 23:04:27 +0300

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.

Thanks,
     Yaron

On 26.8.2011 22:00, [email-masked] wrote:
>
> ------------------------------
>
> Message: 4
> Date: Fri, 26 Aug 2011 12:11:44 -0400
> From: "Blumenthal, Uri - 0668 - MITLL"<[email-masked]>
> To: "[email-masked]'"<[email-masked]>, "[email-masked]'"
> 	<[email-masked]>
> Cc: "[email-masked]'"<[email-masked]>
> Subject: Re: [TLS] TLS and middleboxes again
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> 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:[email-masked]]
> Sent: Friday, August 26, 2011 11:37 AM
> To: Juho V?h?-Herttua<[email-masked]>
> Cc: [email-masked]<[email-masked]>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 85, Issue 19
> ***********************************

---

From: Yoav Nir <[email-masked]>
Date: Fri, 26 Aug 2011 23:27:52 +0300

> 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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 26 Aug 2011 16:45:32 -0400

> 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.

> to issue an HTTP redirect, e.g. to display a copy of the company's 

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

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Fri, 26 Aug 2011 19:55:53 -0400

I agree with Daniel. 

--
Regards,
Uri

----- Original Message -----
From: Daniel Kahn Gillmor [mailto:[email-masked]]
Sent: Friday, August 26, 2011 04:45 PM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] TLS and middleboxes again

	--dkg

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 26 Aug 2011 20:38:35 -0400

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