Re: [TLS] chairs - please shutdown wiretapping discussion...

[Stephen Farrell <[e-mail]>]

Hiya,

On 11/07/17 12:02, Ted Lemon wrote:
> On Jul 10, 2017, at 5:35 PM, Stephen Farrell
> <[e-mail]> wrote:
>> Consider SMTP/TLS. Where one MTA on the path supports this. Say
>> it's one operated by an anti-spam company for example. That is
>> clearly not the sender nor recipient.
>> 
>> That meets all 4 points in 2804, right?
> 
> I don't buy this, Stephen.   The anti-spam company is not an
> eavesdropper.

This draft proposes a way for an eavesdropper who recorded
the cihphertext packets from anywhere to use a standardised
interface to get a small package of key material from the
anti-spam company (via coercion or collusion), that allows
the eavesdropper to decrypt all the TLS protected email
traffic sent via the anti-spam company. Looked at one way,
tt amounts to standardising a key exfiltration attack.

> 
> What I don't understand about your approach to this draft is that it
> seems to me that the draft is obviously describing an exploit in TLS
> 1.3, for which a mitigation exists: remember keys, and refuse to
> communicate with an endpoint that presents a key you've seen before.

The TLS server doesn't need to do things in a way that
a TLS client can detect.

> So rather than opposing the publication of the static keys draft, why
> not work on mitigating the attack it describes?   This attack exists
> whether the static keys draft is published or not.

Good/better TLS1.3 forward secrecy is being discussed as
part of the normal work in the WG. It is for sure always
possible to manage keys badly, but this draft proposes
an API to expose private key materials which is not the
same thing as bad implementation or management at all.

Cheers,
S.

> 
>