The idea of encrypting TLS record headers has come up before, the most
important purpose being to hide record lengths and boundaries and make
fingerprinting and traffic analysis harder. I had convinced myself that
goal this would be "too hard" to accomplish in TLS 1.3, but after
further thought I'
Hi Peter,
On 11/28/15 12:15 PM, Peter Gutmann wrote:
> Bryan A Ford writes:
> SSL/TLS have used unencrypted lengths for twenty years without there being any
> (known) attack or weakness based on this.
Leaving all headers in the clear (and in particular record lengths) is a
huge sid
On 11/27/15 5:21 PM, Henrick Hellström wrote:
> On 2015-11-27 15:35, Bryan A Ford wrote:
>> The idea of encrypting TLS record headers has come up before, the most
>> important purpose being to hide record lengths and boundaries and make
>> fingerprinting and traffic anal
On 11/29/15 12:29 PM, Henrick Hellström wrote:
> On 2015-11-29 10:48, Bryan A Ford wrote:
>> In short, leaving TLS headers in cleartext basically hands any
>> eavesdropper a huge information side-channel unnecessarily and precludes
>> anyone*but* the TLS implementation i
On 11/30/15 2:26 AM, Peter Gutmann wrote:
> Bryan A Ford writes:
>
>> Feel free to attack my proposal but then please attack *my* proposal, not
>> the old broken SSH approach.
>
> I was actually commenting on the concept of encrypting headers in general,
> not th
On 11/30/15 2:40 AM, Peter Gutmann wrote:
> Nikos Mavrogiannopoulos writes:
>
>> I believe your proposal is a nice example of putting the cart before the
>> horse. Before proposing something it should be clear what do you want to
>> protect from, what is the threat?
>
> Exactly. If you want to
On 11/30/15 2:54 AM, Short, Todd wrote:
> This brings up an interesting point; having a record length that corresponds
> to the TCP segment size can help hardware implementations such that they
> don't need to deal with scatter/gather; i.e. one TCP segment corresponds to a
> single TLS record.
Thanks Bill for the feedback.
On 11/29/15 6:11 PM, Bill Cox wrote:
> Thanks for the detailed description of why we might want to obfuscate
> TLS record lengths. From a security point of view, the only potential
> attack vector this might create is that the attacker will know in many
> cases the p
On 12/1/15 10:12 AM, Yoav Nir wrote:
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote:
>> On 12/1/15, Viktor Dukhovni wrote:
>>>* Interoperable in the field with various capital-intensive
>>> middle boxen.
>>
>> Which would those be? And what is the definition of capital-intensive
>>
On 12/1/15 4:02 AM, Fabrice Gautier wrote:
> 1) What would be the implications of this for DTLS? (Knowing that one
> difference between TLS and DTLS is the record header)
Good question. Fortunately my proposal should be fairly easy to adapt
to DTLS, with one small trick.
The main issue is that
Some of the parallel discussion on the SSH list - especially comments by
Simon Tatham and Niels Möller - made me think of an alternative design
that would not only hide TLS headers but also ensure that they are
integrity-checked by the receiver *before* the receiver attempts to
interpret the record
Hi Dmitry,
On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> Dear Bryan,
>
> On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <mailto:brynosau...@gmail.com>> wrote:
>
> DTLS:
>
> Now there's still the important question of whether this (new) proposal
On 12/2/15 4:45 PM, Watson Ladd wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum wrote:
>> On 12/2/15, Eric Rescorla wrote:
>>> It's not really clear to me what the anti-traffic-analysis benefit of your
>>> proposal
>>> is over and above just padding everything to a fixed size. That's ce
On 12/2/15 9:13 PM, Dave Garrett wrote:
> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>> Encrypted SNI doesn't give you the kind of protection you think that it
>> does. We (me and a colleague) did a pretty thorough analysis that showed
>> this. It was not a conclusion we expe
Hi Mike,
On 12/2/15 4:14 PM, Mike Copley wrote:
> [...] Not sure if this is the right place to consider, but would DTLS 1.3(?)
> be able to encrypt headers and still handle packet loss and re-ordering? If
> DTLS needs cleartext headers, would it be better to advise one approach for
> both proto
Hi Jens,
On 12/2/15 11:47 AM, GUBALLA, JENS (JENS) wrote:
>> Fortunately the solution is fairly simple: the receiver simply pre-
>> computes and keeps in a small hash table the encrypted sequence numbers
>> of all packets with sequence numbers between H-W and H+W, where H is
>> the highest sequenc
On 12/4/15 9:56 PM, Jim Schaad wrote:
> I will start by re-iterating my initial position that I would prefer that
> the DTLS and TLS analysis is going to be the same in terms of masking the
> header information. So I decided to do some thought experiments about what
> happens if the length were to
While I think the approach I suggested for encrypted DTLS headers would
work, it does have the downsides of (a) the complexity of managing the
hash table of encrypted sequence numbers, and (b) the risk of
desynchronization after long bursts of missed packets.
But further discussion with Philipp Jo
Since a lot of the skepticism toward my encrypted-headers proposal
constituted worries whether the benefits are worth the implementation
cost/complexity, I decided to implement it and find out what that cost
and complexity actually is. See this github repo:
https://github.com/bford/nss
H
19 matches
Mail list logo
