Subject: Re: [TLS] TLS Proxy Server Extension

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Aug 2011 10:15:59 +0300

On 8/1/11 9:28 AM, "Marsh Ray" <[email-masked]> wrote:

>
>> The intent of the authors is to enable TLS to be
>> used when an proxy is present,
>
>But the intent of TLS is to prevent man-in-the-middle attacks, i.e., to
>prevent you from proxying it.
>
>Just because you can exploit it almost reliably with a custom root CA on
>today's clients doesn't mean that it's not deeply contrary to the
>security architecture of TLS.
>
>Design a secure way for the legitimate endpoints to agree to share some
>session key material with you in a way that doesn't impersonate anyone.
>I might even support such an extension (but good luck convincing the
>servers of the world).

Actually, with this extension, the proxy does not need to generate a "fake
certificate". It's fine for the proxy to present a certificate for
"CN=tlsproxy.example.com" and convey the real certificate in the
extension. Of course, clients would have to explicitly trust the proxy,
but that can be added as part of adding support for the extension.

As for servers, it's possible to change the tls-proxy format in
ClientHello to have a "role" field that could be either "client" or
"proxy". Then the servers would be able to reject connections from
proxies. Would that make it more acceptable?

>
>> and to make clients informed about both
>> the proxy and the server, and to provide cryptographically strong
>> authentication of both.
>
>This concept of polyamorous TLS is more radical than its proponents want
>to accept.

Practically, I don't see this happening. The IETF generally does not
radically alter protocols to fit the needs of middleboxes, it's the
middleboxes that have to adapt at least at first. Later we do see how the
active mode of FTP replaces the passive mode because it fits NAT better.

---

From: David McGrew <[email-masked]>
Date: Mon, 1 Aug 2011 05:25:52 -0700

Again, it seems that you do not quite understand what we are trying to  
achieve.   There is current practice that uses proxies in a way that  
is bad for clients (and you outline many of the reasons below).  We  
aim to improve the situation for clients and the security of the  
overall solution.  One important point: it is possible to design a  
solution in which the proxy does not contain a CA.

Propagating TLS session key material is a worse idea for a lot of  
reasons.  It would be a fragile solution in which easy-to-make  
implementation mistakes could undermine security.  It would require  
considerable new implementation work.  It would make crypto validation  
considerably harder if not impossible.   If it aimed to preserve end- 
to-end authentication, it would be fundamentally incompatible with  
Authenticated Encryption in general and the AEAD facility in TSL 1.2  
in particular, and it would probably end up getting misused and abused  
in practice.  If it did not aim to preserve end-to-end authentication,  
then it would require considerable changes to the TLS protocol, to  
prevent keystream insertion attacks and keystream re-use.  Perhaps  
worst of all, it would create a mechanism that could more easily be  
abused; a server could (mis)use it and give away session keys without  
the knowledge or consent of the client.

I will work to make the next version of the draft more clear and more  
complete.

David

On Jul 31, 2011, at 11:28 PM, Marsh Ray wrote:

> On 07/30/2011 08:20 AM, David McGrew wrote:
>> It seems that you do not understand the intent of the draft or the  
>> authors.
>
> The intent is nearly irrelevent. The text of the spec and the bits  
> on the wire are what matters.
>
>> The use case here is web filtering as it is used by organizations and
>> consumers, in which a consumer or an organization chooses to use a
>> service or a product that acts as an HTTP proxy, and configures their
>> clients to do so. It is desirable in such cases to use TLS whenever
>> possible, and it is certainly desirable that the client be able to
>> authenticate the proxy.
>
> HTTP has explicit support for proxies and you can connect to them  
> securely via TLS already. Wouldn't this all be done more  
> appropriately at the HTTP layer?
>
> But the intent of TLS is to prevent man-in-the-middle attacks, i.e.,  
> to prevent you from proxying it.
>
> Just because you can exploit it almost reliably with a custom root  
> CA on today's clients doesn't mean that it's not deeply contrary to  
> the security architecture of TLS.
>
> Design a secure way for the legitimate endpoints to agree to share  
> some session key material with you in a way that doesn't impersonate  
> anyone. I might even support such an extension (but good luck  
> convincing the servers of the world).
>
> This concept of polyamorous TLS is more radical than its proponents  
> want to accept.
>
> Current TLS:
> Client strongly authenticates server via trusted CA
> Server may authenticate client, but usually server relies on client  
> to stop S-C MitM
> Any proxy can only slow or drop connections
>
> "TLS proxy" via root cert on client:
> Client can't authenticate server any stronger than weakest proxy  
> allows
> Client may not even be aware of proxies
> Any proxy may degrade security of connections arbitrarily
> Any proxy may get pwned and expose its root CA private key
> Any proxy may prevent the use of protocol features and extensions
> Any proxy can both read and modify plaintext
> Server can't authenticate client at all, client certs are busted  
> forever
> Server can't authenticate proxy at all
> Server probably can't detect proxy downgrade
> Proxy relies on client to stop P-C MitM
> Server relies on proxy to stop S-P MitM
>
>> The client should be able to decide if it
>> accepts the proxy for a particular session, and the scope of the  
>> proxy
>> should be limited, and the proxy should not lie to the client. The
>> client should also have the full information about the server on the
>> other end of the connection.
>
> But by installing the custom root CA in the browser you've weakened  
> the guarantees (which derive from "MUST"s and "MUST NOT"s) to merely  
> "should"s and "should not"s. I.e., you've removed the strong crypto  
> guarantees from the perspective of the legitimate client and (by  
> extension) the server, who are the only parties given any security  
> guarantees at all in the current TLS RFCs.
>
>> We oppose the development of a technology that would help a country  
>> spy
>> on its citizens,and we certainly oppose the development of  
>> standards in
>> that area.
>
> Meh. It already exists for anyone controlling a trusted root or sub- 
> CA, why would they choose to turn on this functionality?
>
>> The IETF can't control how the technologies that it develops
>> are used, or who uses them, of course, which makes it imperative to  
>> not
>> develop any mechanisms that could be used in that way.
>
> Put it another way: don't develop mechanisms that break basic  
> security guarantees. Even better would be to improve on them.
>
> - Marsh

---

From: David McGrew <[email-masked]>
Date: Mon, 1 Aug 2011 05:32:11 -0700

On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote:

>> CA on
>> some

Agreed.  It may also be desirable to add an authorization attribute to  
the certificate to explicitly label it as a proxy certificate.

> proxies. Would that make it more acceptable?

This is a good idea.  It does not provide strong authentication of who  
the proxy is, but it does inform about its presence.

David

>> want

---

From: David McGrew <[email-masked]>
Date: Mon, 1 Aug 2011 07:19:08 -0700

On Aug 1, 2011, at 12:15 AM, Yoav Nir wrote:
> "proxy".

a further thought in this direction.  The server could sign the  
extension that it gets from the proxy, and that signature could be  
returned to the client, along with the data that was signed.  This  
would give the client a strong confirmation that the server was aware  
of the proxy.   From a security standpoint, this is good.  From a  
deployability standpoint, it would require that servers are modified  
to understand the extension, which is not so good.

David

---

From: Yoav Nir <[email-masked]>
Date: Mon, 1 Aug 2011 18:08:17 +0300

>to understand the extension, which is not so good.

That depends on what the clients do with this strong confirmation. For
example, I can see them showing the regular padlock even without the
signature, but displaying the EV indication only when they get it.

I'm also thinking about whether we can get client certificates to work.
The hard problem is that Certificate Verify signs the handshake messages,
and those are not available to the client. I don't think we want to send
all the previous handshake messages in the extension, so getting this to
work would also require a server-side change.

Yoav

---

From: Marsh Ray <[email-masked]>
Date: Mon, 01 Aug 2011 10:28:07 -0500

> work would also require a server-side change.

You could just send the MD5/SHA-1/SHA-256 hashes of the messages, which 
is what the client cert signs.

Of course, this amounts to the client being willing to sign basically 
anything for the proxy, carte blanche. If the client's cert were valid 
for other things such as serving TLS or code signing that could 
represent a significant escalation of privilege.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Aug 2011 18:15:16 +0200 (MEST)

> solution in which the proxy does not contain a CA.

You're trying to give the proxy the authority to impersonate
_every_ server.  Whether it is through an super-CA-cert or whether
you're extending the protocol so that the client believes a forwarded
certificate with _no_ proof-of-posession for that cert is a mere
implementation detail, and has no impact of the size of the security
problem that you want to newly create.

> implementation mistakes could undermine security.

I'm sorry, but that is a completely bogus claim.

If the proxy is terminating both TLS connections, it will have access
to traffic encryption and mac keys of both connections can can leak
those just as easily.  Sharing the traffic encryption keys will not
make this any worse.

>
> It would require considerable new implementation work.

You mean because it would require an additional network channel to
talk to the proxy? yes.  It can not happen "by accident".

>
> It would make crypto validation considerably harder if not impossible.

Nope.  That is orthogonal.

>
> If it aimed to preserve end-to-end authentication, it would be
> fundamentally incompatible with Authenticated Encryption in general
> and the AEAD facility in TSL 1.2 in particular, and it would probably
> end up getting misused and abused in practice.

Correct, the use of AEAD would break the security, since this mode does
not use seperate traffic encryption and mac keys.  Personally, I consider
AEAD a bad idea, so I don't mind disabling these cipher suites when
traversing such a proxy.

>
> If it did not aim to preserve end-to-end authentication,  

I have no clue what you mean.  If the proxy terminates the clients
TLS connection and establishes a new connection to the real server,
then it will have to impersonate the real server to the client in any case
and will always have all keying material available to do anything bad
to either or both peers.

So security-wise, the TLS proxy that you are proposing is at the
far end of badness, there is _nothing_ that can possibly be worse,
but a few thinghs might be *MUCH* better.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Aug 2011 18:28:12 +0200 (MEST)

David McGrew wrote:
> spy on its citizens, and we certainly oppose the development of  
> standards in that area.

There is no fundamental difference between a country spying on citizens
and a company spying on employees.  Our constitution does not make a
difference between these two (but admittely, some lower courts haven't
grasped the legally binding constitutional court decisions yet).

-Martin

---

From: David McGrew <[email-masked]>
Date: Mon, 1 Aug 2011 12:15:22 -0700

On Aug 1, 2011, at 9:15 AM, Martin Rex wrote:

> _every_ server.

On the contrary, the goal here is to not have the proxy impersonate  
any other device, at least not impersonate in the cryptographic sense.

>  Whether it is through an super-CA-cert or whether

It's hard to parse that sentence, but if I understand you right, you  
think that it is important for the client to have a strong assurance  
that the subject of the server certificate is an active participant in  
the session.   I agree that is a highly desirable property.

I think the right theoretical approach to analyzing this sort of  
protocol would be to start with a formal model of TLS as a two-party  
authentication protocol, and extend it to accomodate a three-party  
system with the appropriate role definitions.  Fortunately, only the  
authentication aspects need to be considered, and some of the key  
establishment goals can be ignored, which makes the analysis easier.   
If we had the freedom to design the system from scratch, the obvious  
approach would be to have C, S, and P each issue nonces that get  
signed by each other party, along with the other data that gets  
currently signed, and indication of the role of each signer.  What is  
most interesting is: how close can one get to this ideal protocol by  
extending TLS?

> Nope.  That is orthogonal.

On the above three points: allowing a proxy to coordinate betwen two  
TLS sessions allows one to preserve most of the TLS protocol and  
implementation.   In contrast, a solution that propagates session keys  
will require new implementation work for the data plane, state  
management, and so on.  If the proxy attempts to modify the session,  
all sorts of significant crypto problems will crop up.  There will be  
HTTP proxies that expect to modify the traffic, and it would be unwise  
to expect that a proxy implementer would respect the injunction to not  
modify the session, if a specification for session key propagation  
were developed.

It seems like a major difference that we have is that you expect a  
"read only" solution to be viable, while I don't.  A read-only  
decryption proxy would be considerably easier to implement correctly.   
However, I have zero confidence that a read-only decryption proxy  
would not evolve into a read/write proxy, which would introduce very  
significant security problems.

> AEAD a bad idea, so I don't mind disabling these cipher suites when

Your personal opinion on AEAD goes against a lot of theory and  
standards work of the last decade.  Have you considered providing your  
criticisms in writing?

> I have no clue what you mean.

Then think about the situation in which the proxy has the encryption  
keys and the authentication keys, and yet there is just a single TLS  
session, and consider the changes that would be needed to the TLS  
protocol in order to retain security even when the proxy is modifying  
the session data.

>  If the proxy terminates the clients
> then it will have to impersonate the real server to the client

No, that's not right, at least not if "impersonate" is meant in the  
cryptographic sense.   If "impersonate" is meant in the sense that a  
proxy can modify the traffic passing through it, then yes, that is a  
goal for the system; it is a requirement if TLS is to be used to  
protect communications when an HTTP proxy is present (for many types  
of proxies).

> in any case

In any solution in which a proxy has session keys, it is required that  
the client and server trust the proxy to do the right thing.

One thing that really surprises me about your line of thinking is the  
fact that you feel that a protocol that can propagate a session key to  
a proxy would encourage better respect of privacy.  A server could use  
that protocol to pass keys to a middlebox without the knowledge or  
consent of the client, and the client could do so without the  
knowledge or consent of the server.   With the key propagation  
approach, there is very little that you and I can do to prevent this  
sort of behavior.  (Side note: one could design a solution that  
required both the client and server to approve of the presence of the  
proxy; in fact, I've been through that design exercise.  However, it  
would be easy for implementers to ignore the stipulation that both  
sides accede to the proxy, and they would be motivated to do so.)

I think we've both stated our views well enough that people have a  
reasonable idea of what we think.   It would be good to let others who  
care about the topic have a chance to offer their own thoughts.

David

---

From: Martin Rex <[email-masked]>
Date: Mon, 1 Aug 2011 22:38:31 +0200 (MEST)

David McGrew wrote:
> Martin Rex wrote:

Exactly in that sense.  You do not have the slightest proof that
the server, which your proxy impersonates, is actually involved.
The proxy could be making up the entire conversation and the
client will not be able to tell the difference.

> system with the appropriate role definitions.

Been there, done that, and really disliked it:
     http://tools.ietf.org/html/draft-housley-evidence-extns-01

> implementation.

You mean by having the entire TLS security architecture walk the plank,
you could get away with fairly minor code changes?

> significant security problems.

Such an evolution would have the prerequisite of a client cooperating.

And your solution to not have pretty TLS loose virginity at some point
in the future, is to rape her right away, i.e. start with an
almighty TLS proxy?

-Martin

---

From: David McGrew <[email-masked]>
Date: Mon, 1 Aug 2011 17:13:14 -0700

> in the future, is to rape her right away, i.e. start with an

Those are colorful metaphors.  I assume that if you are willing to  
deploy such rhetorical excess, you do not actually understand what is  
being proposed.

David

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Aug 2011 09:19:58 +0300

>>> significant security problems.

Decryption-only through sharing of keys would not work. Some of the processing to be done cannot be done by a passive eavesdropper. For example, if you send me an MS-Word document to my gmail account, and I would like to download it, the way to check for malware is for the proxy to download the entire file, scan it for malware, and then forward it to my computer. A passive eavesdropper would finish collecting the file too late - by then I already have it. An active proxy is necessary.

> deploy such rhetorical excess, you do not actually understand what is  

I think he's missing the baseline. The baseline is that TLS proxies work well enough that companies deploy then. Even in Europe. There are some downsides to using them: client certificates and PSK suites don't work. Certificate and CA pinning don't work. The user cannot verify the actual server certificate chain. The EV indication is gone. But all these are not blocking administrators from deploying TLS proxies. They may be blocking sites from using client certificates or PSK suites, although there are plenty of other things blocking those (but that's from another thread)

This extension may help with those deficiencies. With or without the extension, the existence (or possibility) of the proxy is visible to the user, because you need to install a CA certificate. A user can choose not to use the corporate network for accessing HTTPS sites where he's not comfortable with having the content inspected. The fact that the server is not similarly given a choice may be a problem, but that is a property of using TLS without client authentication. The extension can help, but only if the proxy uses it.

Yoav

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 02 Aug 2011 11:51:06 +0200

The discussion in a nutshell:

http://www.dilbert.com/fast/2011-08-02

On 2011-08-01 21:15, David McGrew wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 2 Aug 2011 15:18:11 +0300

>is what the client cert signs.

Alternatively, we could have the client sign its own ClientHello, and send
that in the Certificate Verify payload. The proxy would send the client's
ClientHello in the extension, and forward the client's CertificateVerify.
Then we don't have the escalation of privilege.

---

From: Ken Peirce <[email-masked]>
Date: Tue, 2 Aug 2011 05:51:00 -0700 (PDT)

After watching the back and forth on TLS proxies, and the ever increasing complexity of proposed bandaids to cover individual vulnerabilities, this is starting to look like rearranging the deck chairs on the Titanic. 

TLS is used by people to insure end to end integrity and privacy, usually, with PKI. Users are protected from intermediate parties if the system architects and TLS management by the controlling application have correctly handled the design of the PKI(e.g. insuring that the CN is in fact the desired name and that the root certificate applicable to the presented certificate are as expected, etc.). 

If you want to proxy, you are delegating trust to another entity and effectively running a tandem pair of TLS sessions. 

IMHO, this is not a protocol issue. It is a systems engineering exercise in trust relationships. 

Most security people I know would agree with me that complexity is the enemy of security. Adding all of these modifications to the protocol only increases the chances of introducing new holes in its protection.

Ken Peirce

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 03 Aug 2011 01:11:49 +1200

Ken Peirce <[email-masked]> writes:

>TLS is used by people to insure end to end integrity and privacy, usually,
>with PKI. Users are protected from intermediate parties if the system
>architects and TLS management by the controlling application have correctly
>handled the design of the PKI

Exactly.  The whole point of TLS is to provide a secured tunnel from source to
destination, which includes defence against MITMs.  If someone wants to do a
MITM, violating a principal design feature of the protocol, then that's their
problem, and not TLS's.  

>IMHO, this is not a protocol issue. It is a systems engineering exercise in

Exactly.  The response to this is "don't do that, then", not "we'll completely
break our protocol to make it do the crazy stuff you want".

(If people really want to deploy MITM boxes, put a wildcard cert on the MITM.
That's how cellphone gateways have been doing it for years).

Peter.

---

From: Matt McCutchen <[email-masked]>
Date: Tue, 02 Aug 2011 12:31:16 -0400

On Tue, 2011-08-02 at 09:19 +0300, Yoav Nir wrote:
> Decryption-only through sharing of keys would not work. Some of the
> processing to be done cannot be done by a passive eavesdropper. For
> example, if you send me an MS-Word document to my gmail account, and I
> would like to download it, the way to check for malware is for the
> proxy to download the entire file, scan it for malware, and then
> forward it to my computer. A passive eavesdropper would finish
> collecting the file too late - by then I already have it. An active
> proxy is necessary.

You are confusing layers.  TLS relies on the flow control of the
underlying stream.  The proxy would have to split the TCP connection in
order to collect the entire file, but it would ultimately send the
collected TLS records on to the client verbatim, so the TLS-level
behavior would be passive.

> I think he's missing the baseline. The baseline is that TLS proxies
> work well enough that companies deploy then. Even in Europe. There are
> some downsides to using them: client certificates and PSK suites don't
> work. Certificate and CA pinning don't work. The user cannot verify
> the actual server certificate chain. The EV indication is gone. But
> all these are not blocking administrators from deploying TLS proxies.
> They may be blocking sites from using client certificates or PSK
> suites, although there are plenty of other things blocking those (but
> that's from another thread)
> 
> This extension may help with those deficiencies. With or without the
> extension, the existence (or possibility) of the proxy is visible to
> the user, because you need to install a CA certificate. A user can
> choose not to use the corporate network for accessing HTTPS sites
> where he's not comfortable with having the content inspected. The fact
> that the server is not similarly given a choice may be a problem, but
> that is a property of using TLS without client authentication. The
> extension can help, but only if the proxy uses it.

All agreed.

A person using a corporate laptop has no expectation of privacy from the
company.  The proxy extension just offers a technically more capable
solution for that scenario.

No one is proposing, per se, that TLS interception be used in any more
places than it is now.  Of course, interception may now be used in
places where it was always desired but could not be used before due to
protocol issues.  However, it's hard to believe that the proxy extension
would change the market and/or legal forces that currently restrain ISPs
from routinely intercepting customer traffic, if that is what Martin is
worried about.

The TLS WG may have a personal distaste for the use case addressed by
the extension.  But I would reason that the use case is valid, thus the
extension is worthy of standardization to get interoperable
implementations, and the TLS WG is the best venue available for
technical discussion.  As David explained
(https://www.ietf.org/mail-archive/web/tls/current/msg07920.html), the
use case does not constitute wiretapping as defined in RFC 2804.

-- 
Matt

---

From: Martin Rex <[email-masked]>
Date: Tue, 2 Aug 2011 19:30:33 +0200 (MEST)

> solution for that scenario.

Not everyone is living in totalitarian countries where this might apply.

As I previously said, our constitution provides fundamental gurantees
of privacy, and protects against both, government agencies spying
on citizens as well as employers spying on employees.

> from routinely intercepting customer traffic, if that is what Martin is

No, it is primarily about the employer spying on employee case, which
has been clearly ruled unconstitutional in Germany.  But the stiff penal
code that might provide sufficient deterrant for ISPs does not universally
apply to employers, leaving you with civil action an "cease and desist"
and a number of completely clueless entry courts.

> use case does not constitute wiretapping as defined in RFC 2804.

I haven't heard any use cases for the TLS proxy in this discussion
that are not factually equivalent to wiretapping.

-Martin

---

From: Joshua Davies <[email-masked]>
Date: Tue, 2 Aug 2011 17:27:11 -0500

> that are not factually equivalent to wiretapping.

Hm - it may be factually equivalent to wiretapping, but I can think of a
perfectly legitimate use case for a TLS proxy which MITM's a client, with
that client's express consent and knowledge of course - wire-level debugging
of an encrypted session.  I've set something like this up a couple of times
to debug a server that doesn't accept plaintext connections but is still not
behaving correctly; I create a proxy that presents a self-signed certificate
to the client, ignore the security pop-up warning, and then proxy again to
the server (logging everything in between).  In this case, I'm
"wiretapping", but I'm wiretapping myself.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 3 Aug 2011 09:23:57 +0300

On Aug 3, 2011, at 1:27 AM, Joshua Davies wrote:

> Hm - it may be factually equivalent to wiretapping, but I can think of a perfectly legitimate use case for a TLS proxy which MITM's a client, with that client's express consent and knowledge of course - wire-level debugging of an encrypted session.  I've set something like this up a couple of times to debug a server that doesn't accept plaintext connections but is still not behaving correctly; I create a proxy that presents a self-signed certificate to the client, ignore the security pop-up warning, and then proxy again to the server (logging everything in between).  In this case, I'm "wiretapping", but I'm wiretapping myself.

A TLS proxy is just a piece of technology, much like a microphone and a tape recorder. Legality depends on the use, not on technology.

The use-case that interests me is deep firewall inspection. HTTP connections are routinely inspected by firewalls for downloaded malware, cross-site scripting, and various other attacks. Without a TLS proxy, HTTPS connections can either slip under the radar or get blocked entirely. That would have been fine a few years ago, when SSL was only used for shopping and banking sites (you could defer your shopping and banking for when you were home). These days the use of HTTPS is becoming more prevalent, so blocking HTTPS is no longer a good option. A TLS proxy allows an organization to use HTTPS while still applying company policy and defenses.

I'm not saying this is all good. There are some real problems with using a proxy:
- The same technology can be used for wiretapping, and the user cannot tell the difference between a good proxy and an evil one.
- The client does not get to validate the server on its own (the subject draft is an attempt to solve this)
- Client certificates and PSK ciphersuites are broken.

I think with a little modification the draft can solve the first two problems.

Yoav

---

From: "Kemp, David P." <[email-masked]>
Date: Wed, 3 Aug 2011 16:55:57 -0400

WARNING: contains banned part

Subject: RE: [TLS] TLS Proxy Server Extension
From: "Kemp, David P." <[email-masked]>
To: "David McGrew" <[email-masked]>, <[email-masked]>
Cc: "Philip Gladstone" <[email-masked]>, <[email-masked]>
Date: Wed, 3 Aug 2011 16:55:57 -0400

From: David McGrew
> protect communications when an HTTP proxy is present (for many types  

A TLS connection between S and C provides integrity protection (which by
definition is impossible without authentication): C knows that data it
receives is identical to that sent by S.

How do you propose to define roles that extend integrity properties to a
three-party protocol?  C must know that data it receives from S is sent
by S, with no insertions or deletions.  And that data it receives from P
was sent by P with no insertions or deletions.  "Modifying" traffic is
fundamentally incompatible with data integrity - the concept is
meaningless.  There must be either two independent unmodifiable data
streams between C and S and between C and P, or there must be a single
stream between C and P, where C trusts P to be the data provider without
knowing or caring where P got the data in the first place.  That is what
is meant by impersonation.

In an application protocol it would be appropriate to tag sections of
data that have different properties and originated from different
sources - think chat room, or a portion-marked word document.  TLS
claims to protect an application-independent data stream - I have no
idea how you define semantics of a 3-party "session" without becoming
application-specific.

Dave

---

From: David McGrew <[email-masked]>
Date: Wed, 3 Aug 2011 14:36:27 -0700

> idea how you define semantics of a 3-party "session" without becoming

The idea of authentication in which two or more parties are trusted to  
create authentication tags or signatures occurs in both crypto theory  
(group signatures and threshold signatures, for instance) and crypto  
standards (such as group authentication as defined in RFC 3740 and  
used in RFC 5374).  Security models in which one party can modify data  
created by another can be sound and consistent, but of course we need  
to be careful about definitions, as you are pointing out.  (As an  
extreme example, data aggregation in sensor networks allow many  
different senders to affect a single piece of data.)

It would be most correct to describe the goals of the draft as  
establishing a pair of confidential and authenticated data streams  
between C/P and P/S, while having a three-party entitiy  
authentication.   I think a good way to describe the goal would be:  
multiparty entity authentication with pairwise key establishment.

David

---

From: Ralph Holz <[email-masked]>
Date: Fri, 05 Aug 2011 12:56:21 +0200

Hi,

> multiparty entity authentication with pairwise key establishment.

On a related note, the following patent has just been brought to my
attention:

http://www.google.com/patents?id=MjTHAAAAEBAJ

In essence, what is proposed is that a client consents to monitoring of
its TLS connection. The assignee is Bluecoat - they sell TLS proxies,
among other things.

Ralph