Subject: [TLS] Asymmetric TLS

From: Phil Lello <[email-masked]>
Date: Mon, 4 Apr 2016 18:24:52 +0100

Hi,

I have a use-case for allowing an MITM to monitor traffic, but not
impersonate a server, and to allow MITM signing for replay of
server-responses to support caching.

As far as I'm aware, TLS currently only supports a shared-secret once
session initialisation is complete, so I'd need to extend the protocol to
support asymmetric encryption for the session.

Would there be interest in extending TLS to:
  - allow monitoring-with-consent (based on asymmetric encryption)?
  - allow re-signing from an authorised MITM to support caching?

Best wishes,

Phil Lello

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Apr 2016 14:57:51 -0300

>   - allow re-signing from an authorised MITM to support caching?

no

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Apr 2016 15:00:39 -0300

Let's not do this.

See https://www.ietf.org/mail-archive/web/tls/current/msg19347.html for an
alternative design for this that does not require weakening TLS.

-Ekr

On Mon, Apr 4, 2016 at 2:24 PM, Phil Lello <[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 5 Apr 2016 15:47:35 +0000

>   - allow re-signing from an authorised MITM to support caching?

This is very bad; no.

---

From: Sean Turner <[email-masked]>
Date: Tue, 5 Apr 2016 14:29:11 -0300

With my chair hat on, I won’t comment one way or the other on whether this should be done, but we have gone down this path before.  As I recall, the proposal was pretty resoundingly rejected.

But, what I will say as chair is that this would most definitely require a charter change for the WG.

spt

> On Apr 04, 2016, at 14:24, Phil Lello <[email-masked]> wrote:
> 
> Hi,
> 
> I have a use-case for allowing an MITM to monitor traffic, but not impersonate a server, and to allow MITM signing for replay of server-responses to support caching.
> 
> As far as I'm aware, TLS currently only supports a shared-secret once session initialisation is complete, so I'd need to extend the protocol to support asymmetric encryption for the session.
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 5 Apr 2016 22:20:20 +0100

> require a charter change for the WG.

FYI: you'd also have to climb over an AD-dead-body to get that.

S.

---

From: Bill Frantz <[email-masked]>
Date: Tue, 5 Apr 2016 15:33:06 -0700

To avoid a lot of "Over my dead body" comments, these 
requirements should be met with a very visible man in the middle 
and two (or more) TLS sessions. This architecture should provide 
some security from unwanted men in the middle, as well as making 
it obvious to the endpoints who that man in the middle is.

Cheers - Bill

On 4/5/16 at 10:29 AM, [email-masked] (Sean Turner) wrote:

>With my chair hat on, I won’t comment one way or the other on 
>whether this should be done, but we have gone down this path 
>before.  As I recall, the proposal was pretty resoundingly rejected.
>
>>As far as I'm aware, TLS currently only supports a shared-secret once session initialisation is complete, so I'd need to extend the
>protocol to support asymmetric encryption for the session.
>>

---------------------------------------------------------------------------
Bill Frantz        |"Web security is like medicine - trying to 
do good for
408-356-8506       |an evolved body of kludges" - Mark Miller
www.pwpconsult.com |

---

From: "Sniffen, Brian" <[email-masked]>
Date: Wed, 6 Apr 2016 04:49:37 +0000

I suspect the right place to do this is not at the TLS layer.  As Bill said: do it with two TLS sessions, and then provide authenticated, cacheable objects.  The sub-resource-integrity system <https://www.w3.org/TR/SRI/> tried to achieve that, and seems to get pretty close.

-Brian

> On Apr 4, 2016, at 1:24 PM, Phil Lello <[email-masked]> wrote:
> 
> Hi,
>

---

From: Rick van Rein <[email-masked]>
Date: Wed, 06 Apr 2016 08:32:42 +0200

Hello Phil,

> server-responses to support caching.
This sounds like attack monitoring (going beyond DoS for which SNI
frequencies might already be helpful).  This used to be possible by
passing certificate private keys, until we all embraced (EC)DHE.  This
is still an option for you of course, since you're violating the idea of
(EC)DHE anyway, at least between the monitor and its related TLS peer.

> support asymmetric encryption for the session.
I wonder if you'd need to extend the *protocol* or rather its
*implementation* to share private/secret key material.  You could
probably create a side-channel over which you communicate this
efficienctly, based on the random pieces in Hello, for instance.  Any
such implementation would sound the alarm bells for this option (and
probably not make it a default option) that the TLS protocol can't ring
because it is just a protocol.

My suggestion would be to let the monitor supply the private/secret key
material its related TLS peer, so it has more control; also, for TLS
implementations the import of key material is perhaps less scary than
the export (or more possible, if PKCS #11 is used).  Your monitor might
decide to let go of monitoring traffic, to monitor other traffic and
perhaps to share key material between certain sessions when under
attack.  Be careful with all of this though!

> - allow re-signing from an authorised MITM to support caching?
Clearly, the WG does not like this idea.  Same with me.  But if you
tried something implementation-specific, or perhaps even standardise an
explicit side-channel protocol, you may be more likely to get the work
done because that would constitute an explicit and independent choice on
the part of the administrators.  TLS is so full of options that the eyes
of admins already glaze over -- what you are proposing is explicit
weakening of TLS, and it could slip into a configuration too easily as
part of the confusion that the complexity of the protocol already causes.

It could be interesting to let the WG know what your course of action
will be, so we can positively reference any such requests in the future.

Cheers,
 -Rick