Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

[Jacob Appelbaum <[e-mail]>]

On 12/2/15, Eric Rescorla <[e-mail]> wrote:
> On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir <[e-mail]> wrote:
>>
>> I don’t think Bryan’s proposal will hurt the capabilities of a Check
>> Point
>> firewall, and it will make life difficult for me as a developer no more
>> than it will make life difficult for developers of OpenSSL, NSS,
>> SChannel,
>> or any of a dozen other TLS implementations. I don’t know about the other
>> IDS/IPS/Firewall devices.
>>
>
> The people who will be inconvenienced (if any) by changing the record
> framing in an
> externally visible way are not largely developers of middleboxes or stacks
> but
> rather (1) users and (2) client vendors and (3) server operators, who have
> to
> deal with connections being arbitrarily broken and/or damaged by inspection
> devices which expect to be able to observe packet framing.

Those are also exactly the same parties that benefit from the changes.
Other people who benefit are ISPs, who can't log data that encryption
prevents them from seeing, and there are probably others too.

>
> In Seattle, when the topic of stripping off the fixed three bytes of the
> record
> header came up (which would have had a similar impact), we agreed to defer
> it until we had measurements for the level of breakage that it would cause
> (an experiment which we at Mozilla are on the hook for). It seems to me
> that
> this question should be handled similarly.

How can it break something that doesn't yet exist and how can we
measure that? o_0

Again, I'm surprised that no one is attacking the crypto design that
Bryan offered...

All the best,
Jacob