[Cryptography] At what point should people not use TLS?

[Stephen Farrell]

Hiya,

On 11/04/16 23:33, Bill Frantz wrote:
> The working group is trying to come up with a solution which minimizes
> the risks.

Yes, that's being done by various folks. Here's a way to help...

Part of the work is to analyse the impact of 0rtt replayable data
on various protocols. DKG did a fine job of that for DNS/TLS
(DPRIVE) [1]. I'd love to see additional inputs of that nature
so that our decisions about how to most safely describe what is
the (sadly;-) inevitable (foot-gun that is;-) 0rtt replayable
data in TLS1.3. As there are so many protocols that run over TLS,
it will really be valuable to see as many such analyses as we
can in the next few months. So please do consider helping out
in that way, esp. if you can contribute some analysis that is
less likely to be reproduced by others.

So if you have the time and ability, please pick something and
just go do the work and send a mail somewhere visible. In the
worst case, just ping me with a pointer to your analysis and
I'll ensure all of those that are worthwhile are brought to
relevant folks' attention.

Thanks,
S.

PS: Yes, this mail is an invitation to take part in the process
of making imperfect things less imperfect. I don't apologise for
that, it is one of the many things that need doing, and not the
least important as TLS1.3 has many other features/aspects that are
quite a good bit better than using TLS1.2 or earlier. The fact
that we're faced with a tricky set of trade-offs between sticking
with earlier versions vs. getting the latest, with it's dangerous
implement included, is perhaps a sign that we're involved in an
effort that is maturing.

[1]
https://mailarchive.ietf.org/arch/msg/dns-privacy/p0SpGpLBAXZYJhgS3zXWwHBBlw0

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3840 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20160412/0ef1e403/attachment.bin>