Hiya, On 11/07/17 12:02, Ted Lemon wrote: > On Jul 10, 2017, at 5:35 PM, Stephen Farrell > <stephen.farr...@cs.tcd.ie> 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. > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
