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 side-channel, a
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 analysis harder.
>
> How, exact
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 itself from adding any traffic
analysis protection into the system. Encrypting TLS
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 itself from adding any traff
- Original Message -
> 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
Hi all,
> If compression is so important to NNTP, they should add first-class
support. Period. They should not be relying on a poorly conceived
feature which has been repeatedly demonstrated to introduce
vulnerabilities in what is supposed to be a *security protocol* just
because they don't wan
Maybe I'm missing something, but hasn't this issue already been sufficiently
dealt with via padding?
https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2
The record type and version fields are now frozen, and the record length field
is not indicative of the real length if padding i
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 the specific case you'd given. That is, I assumed you'd specifically
chosen the one case
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 thwart traffic analysis, you need to do something
like w
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. This goes along with 8 (or 4) byte record lengths
I believe the consensus supports what is in the current PR.
Cheers,
Joe
On Thu, Nov 26, 2015 at 3:18 PM, Eric Rescorla wrote:
> Joe,
>
> Can you clarify whether you believe consensus is to make the "Recommended"
> list the list in the current PR or the MTI list. I can edit the document
> eithe
Yes. Theoretically, you do seem to have a point.
But, I have so far not come across implementations making an effective usage of
Identity Hint. So, I guess this should not be such a big problem.
Regards,
Jay
**
Hi,
Does anybody have reference code of TLS 1.3, as much
as developed till now, that s/he can share ?
Thanks and Regards,
Sankalp Bagaria.
---
[ C-DAC is on Social-Media too
13 matches
Mail list logo
