The obvious problem with randomly adding fake versions is you have to have
a way of ensuring they won't conflict with *real* future versions - and
whatever pattern you decide upon in order to do that, middleboxes will use
that pattern to filter out fake versions, and fail as soon as you present
one
Thanks for the info. I see a pull request has just been submitted already:
https://github.com/tlswg/tls13-spec/pull/1116
On Tue, Dec 5, 2017 at 1:03 AM, Eric Rescorla wrote:
>
>
> On Mon, Dec 4, 2017 at 1:59 AM, Alex C wrote:
>
>> The obvious problem with randomly adding fa
I'm hesitant to call a 16-bit registry "big" in any context.
But if allocating a value requires a specification, that's probably okay.
(There aren't even close to 2^16 RFCs in total)
On Wed, Mar 21, 2018 at 3:54 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik
> wrote
As I understand it (poorly!) the idea is exactly to have a single system on
the network that monitors all traffic in cleartext.
It's fundamentally impossible to prevent someone from copying all their
traffic to another system in cleartext. If they're going to do it, they
will.
The functionality is
It seems to me that if this is a valid threat model, then all software is
potentially vulnerable.
TLS records are carried over TCP segments. What if an attacker can change
the way records are divided into segments, and thereby trigger a bug in the
record parser?
On Fri, Apr 20, 2018 at 9:40 AM, V
What exactly is the threat model here?
Are you trying to hide a connection from a reverse proxy at the server end?
If so, the server operator should not have deployed a reverse proxy in the
first place.
Are you trying to hide from a MITM proxy that supplies its own certificate?
If so, then what p
tion layer.
>
> This allows us to provide end-to-end security across a proxy (in this
> case the phone) and independent of the underlying protocols.
>
> Does this make sense?
>
> Ciao
> Hannes
>
>
> On 11/07/2017 10:21 AM, Alex C wrote:
> > What exactly is the
