Re: [TLS] TLS 1.3 - Support for compression to be removed

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

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

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

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

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)

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

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,

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

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

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

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

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

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

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

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

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

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

Re: [TLS] PR#345: IANA Considerations

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

Re: [TLS] TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites

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

[TLS] Reference code of TLS 1.3

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