Hello Phil,
> 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.
>
This sounds like attack monitoring (going beyond DoS for which SNI
frequencies might already be helpful). This
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
On 05/04/16 18:29, Sean Turner wrote:
> But, what I will say as chair is that this would most definitely
> require a charter change for the WG.
FYI: you'd also have to climb over an AD-dead-body to get that.
S.
smime.p7s
Description: S/MIME Cryptographic Signature
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.
On 4 April 2016 at 14:24, Phil Lello wrote:
> 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?
This is very bad; no.
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