Re: [TLS] TLS and middleboxes again

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, tls-request@ietf.org wrote:
>
> ------------------------------
>
> Message: 4
> Date: Fri, 26 Aug 2011 12:11:44 -0400
> From: "Blumenthal, Uri - 0668 - MITLL"<uri@ll.mit.edu>
> To: "'nmav@gnutls.org'"<nmav@gnutls.org>, "'juhovh@iki.fi'"
> 	<juhovh@iki.fi>
> Cc: "'tls@ietf.org'"<tls@ietf.org>
> Subject: Re: [TLS] TLS and middleboxes again
> Message-ID:<20110826161051.85A8921F850E@ietfa.amsl.com>
> 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: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
>
>
> ------------------------------
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> End of TLS Digest, Vol 85, Issue 19
> ***********************************