Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

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 > wrote: > > DTLS: > > Now there's still the important question of whether this (new) proposal > could be

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

Dear Bryan, On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford wrote: DTLS: > > Now there's still the important question of whether this (new) proposal > could be made to work in the context of DTLS. For the DTLS case, my > current thinking is that some elements of my earlier

Re: [TLS] Fresh results

On Tue, 1 Dec 2015 14:28:49 -0500 Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf > > This one looks very nasty to fix. Short of disallowing the use of RSA > certificates for TLS 1.2 with the RSA handshake and in

Re: [TLS] Fresh results

On Tuesday, December 01, 2015 02:28:49 pm Watson Ladd wrote: > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf This analysis was done against TLS 1.3 draft 07 from July. It changed to RSA-PSS signatures for handshake messages in draft 09. (current is draft

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

On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford wrote: > 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

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

Jacob Appelbaum writes: >I think the only thing that comes close is when I've named a classified US >government surveillance program (XKeyscore) that would probably have trouble >with it. Why would XKeyscore have trouble with it? Standard off-the-shelf routers, not even

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote: > I don't think even I agree with this idea, but I'll put it out there anyway. > > We're seeing some new secure computing modes in ARM and Intel processors. > Arm has TEE, and Intel has SGX. Both modes basically run at the same speed > as

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

> On 1 Dec 2015, at 4:55 PM, Bryan A Ford wrote: > > 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

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On 1 December 2015 at 08:22, Bryan A Ford wrote: > The 2-byte length field in each record's header no longer indicates > the length of the *current* record but instead indicates the length of > the *next* record. Ensuring that you know the length of the *next* record is

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

On Tue, Dec 01, 2015 at 09:02:34PM -0800, Martin Thomson wrote: > Ensuring that you know the length of the *next* record is difficult > and could dramatically degrade latency, or adding extra bogus padding > or extra bogus records. For instance, I can always send in bursts of > two packets, a

Re: [TLS] Draft status and updates

On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote: > > This clears out the big pipeline stall from PR#316, but probably has > created some bustage. Expect a series of cleanup commits and some > other things that were head-of-line blocked this week and then > draft-11 in the next week

[TLS] Fresh results

https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf This one looks very nasty to fix. Short of disallowing the use of RSA certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I don't see a good fix. I haven't read this paper in detail yet.

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

> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum wrote: > > On 12/1/15, Viktor Dukhovni wrote: >> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote: >> >>> Bryan A Ford writes: >>> It would work just as well

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

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

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

Hi, Hubert Kario wrote: > then we need Best Current Practice for applications describing to them > how TLS needs to be used, e.g. make sure that they are doing writes as > big as possible, checking if timing of responses doesn't leak much > information, etc. Forcing TLS implementation to

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

On 01/12/15 15:22, "TLS on behalf of Yoav Nir" wrote: > >On 1 Dec 2015, at 1:02 PM, Hubert Kario wrote: > > If you think it is practical for the TLS 1.3 standard to specify a > single, fixed record size that all

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

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

Re: [TLS] bikeshed: Forward Security or Secrecy?

I am planning to use "forward secrecy" On Tue, Dec 1, 2015 at 4:17 AM, William Whyte wrote: > If we want to change to “key erasure” we should synch with CFRG and SAAG > to ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so > broken that it

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

On 1 Dec 2015, at 1:02 PM, Hubert Kario wrote: If you think it is practical for the TLS 1.3 standard to specify a single, fixed record size that all implementations of TLS 1.3 must use (i.e., explicitly freeze not only the version field but the length

[TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

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