> On Sep 23, 2015, at 4:17 PM, Jeffrey Walton wrote:
>
>> IMHO, compression adds too many security vulnerabilities to a general
>> purpose secure communication protocol. I think TLS 1.3 is right in
>> eliminating it. It is too big a foot gun.
>
> To play devil's advocate: if (1) compression inc
eld disabled, and
trial-decrypt. This is messier than both of the above, but seems a possible
compromise between modularity and privacy.
What do you think?
Thanks & best,
Björn
[1]
http://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme
--
le (protecting against traffic analysis).
I’m totally in for protecting user privacy. I simply believe that we should
first specify what we want, then see whether we can achieve it, and then build
the mechanism that does it.
Cheers,
Bjoern
--
Björn Tackmann
Postdoctoral Research Scholar
Computer Science & Engineering, UC San Diego
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
+1
> On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan
> wrote:
>
> I prefer (2)
>
>> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wrote:
>>
>> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote:
>>> 1. Use the same key for handshake and application traffic (as in the
>>> current draf
HO it isn't prohibitively expensive either.
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> Original Message
> From: Björn Tackmann
> Sent: Tuesday, June 14, 2016 05:23
> To: tls@ietf.org
> Subject: Re: [TLS] Consensus call for keys
I wanted to explain that on my final slide but then ran over time. It is
discussed in the paper, though. Sorry for the confusion.
Best,
Bjoern
> On Aug 15, 2016, at 4:46 PM, Paterson, Kenny
> wrote:
>
> Sadly, you can't implement XGCM using an existing AES-GCM API, because of the
> way the
