Re: [TLS] Consensus call for keys used in handshake and data messages

On Mon, Jun 20, 2016 at 11:43:41PM -0400, Dave Garrett wrote: > > An idea for an option 4: Keep typing and keying as it currently is > (as of draft 13), but mandate a KeyUpdate immediately following > (and/or before) non-application traffic. We already have a mechanism > to use different keys in

Re: [TLS] Consensus call for keys used in handshake and data messages

On Monday, June 20, 2016 08:39:11 pm Eric Rescorla wrote: > Nobody seems super-excited about either Option 1 or Option 2, so it's > at least worth noting that there's one of the options I claimed was > rejected earlier, namely separately encrypting the content type in > roughly the manner

Re: [TLS] Consensus call for keys used in handshake and data messages

On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla wrote: > > 2. It's odd to just use a piece of the AEAD cipher (the encryption > function), especially if we ever had a really non-composite cipher. > This can be alleviated by using HKDF-Expand to produce the stream > of bits. > If

Re: [TLS] Consensus call for keys used in handshake and data messages

Nobody seems super-excited about either Option 1 or Option 2, so it's at least worth noting that there's one of the options I claimed was rejected earlier, namely separately encrypting the content type in roughly the manner suggested by DKG, Ilari, and Kenny. Thanks for Doug/Felix for prompting me

Re: [TLS] Consensus call for keys used in handshake and data messages

I am abstaining on the choice of alternative 1 and 2 since I do not understand enough the engineering considerations and ramifications of the different choices. Also, I have not put any thought into the privacy issues related to hiding content type and I certainly did not do any formal analysis of

Re: [TLS] Consensus call for keys used in handshake and data messages

Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: >> wasn't that rejected because it breaks boxes that do passive monitoring >> of connections? (and so expect TLS packets on specific ports, killing >> connection if they don't look like TLS packets) > > We're

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi Ilari, On 14/06/2016 20:01, "TLS on behalf of Ilari Liusvaara" wrote: >I too haven't seen an argument (or am I able to construct one >myself) on why using the same key causes more issues than >"more difficult for cryptographers"

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi Ilari, On 15/06/2016 17:23, "TLS on behalf of Ilari Liusvaara" wrote: >On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked

Re: [TLS] Consensus call for keys used in handshake and data messages

On Thu, Jun 16, 2016 at 12:13:28PM -0400, Daniel Kahn Gillmor wrote: > On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > > wasn't that rejected because it breaks boxes that do passive monitoring > > of connections? (and so expect TLS packets on specific ports, killing > > connection if

Re: [TLS] Consensus call for keys used in handshake and data messages

On Thu 2016-06-16 11:26:14 -0400, Hubert Kario wrote: > wasn't that rejected because it breaks boxes that do passive monitoring > of connections? (and so expect TLS packets on specific ports, killing > connection if they don't look like TLS packets) We're talking about the possibility of

Re: [TLS] Consensus call for keys used in handshake and data messages

On Wednesday 15 June 2016 09:44:18 Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > I disagree that this is a low level crypto decision, or at least > > that this is mainly so. > > > > There is the question of whether using the same key for application > > data

Re: [TLS] Consensus call for keys used in handshake and data messages

On Wed 2016-06-15 12:23:38 -0400, Ilari Liusvaara wrote: > On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: >> On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: >> >> To be clear, we're being asked to trade these things off against each >> other here, but there are other

Re: [TLS] Consensus call for keys used in handshake and data messages

I prefer (1) On Wed, Jun 15, 2016 at 5:51 PM Dan Harkins wrote: > > Hello, > > On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > > For background please see [1]. > > > > Please respond to this message indicating which of the following options > > you prefer by

Re: [TLS] Consensus call for keys used in handshake and data messages

Hello, On Mon, June 13, 2016 12:00 pm, Joseph Salowey wrote: > For background please see [1]. > > Please respond to this message indicating which of the following options > you prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in the > current

Re: [TLS] Consensus call for keys used in handshake and data messages

On Wed, Jun 15, 2016 at 09:44:18AM -0400, Daniel Kahn Gillmor wrote: > On Wed 2016-06-15 04:44:59 -0400, Yoav Nir wrote: > > To be clear, we're being asked to trade these things off against each > other here, but there are other options which were ruled out in the > prior framing of the question

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi, Nikos > On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: >> For background please see [1]. >> >> Please respond to this message indicating which of the following >> options you prefer by Monday June,

Re: [TLS] Consensus call for keys used in handshake and data messages

With option (2) would the keys end up being independent anyway? I think we might need to share the sequence number space between the handshake messages and the application data messages to avoid truncation attacks. I might have missed this, but was there a proposal to deal with sequence numbers

Re: [TLS] Consensus call for keys used in handshake and data messages

Just to be clear: the "+1" I sent earlier meant "I agree with Karthik" -- so it means solution (2). > On Jun 14, 2016, at 1:18 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > > Key reuse often ends up causing problems. IMHO a more sound approach is (2). > IMHO it isn't

Re: [TLS] Consensus call for keys used in handshake and data messages

+2 Will Serumgard > On Jun 14, 2016, at 4:22 AM, Watson Ladd wrote: > > > On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" > wrote: > > > > I prefer (2) > > Same. It's clear 1 makes proofs more complicated, making mistakes easier to >

Re: [TLS] Consensus call for keys used in handshake and data messages

I am in favour of option (2). Cheers Ben. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Consensus call for keys used in handshake and data messages

On Tue, Jun 14, 2016 at 11:33:11AM +0300, Yoav Nir wrote: > > > (1) +1 > One important (for me) use case for handshake messages after the > original handshake is client certificate authentication. Disclosing > that the user has just touched the magic resource that causes > certificate

Re: [TLS] Consensus call for keys used in handshake and data messages

I also prefer (2). Cheers, Felix On 14/06/2016 14:45 +0200, Cas Cremers wrote: > It is not quite as simple as saying "(1) makes proofs more complicated" > since it depends on what you are trying to prove. > > (1) makes some styles of standard AKE property proofs (key secrecy, > authentication)

Re: [TLS] Consensus call for keys used in handshake and data messages

It is not quite as simple as saying "(1) makes proofs more complicated" since it depends on what you are trying to prove. (1) makes some styles of standard AKE property proofs (key secrecy, authentication) harder (2) might make some privacy proofs harder Given that the proof-effort has mostly

Re: [TLS] Consensus call for keys used in handshake and data messages

Key reuse often ends up causing problems. IMHO a more sound approach is (2). IMHO it isn't prohibitively expensive either. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.   Original Message   From: Björn Tackmann Sent: Tuesday, June 14, 2016 05:23 To: tls@ietf.org

Re: [TLS] Consensus call for keys used in handshake and data messages

+1 > On Jun 14, 2016, at 7:08 AM, Karthikeyan Bhargavan > wrote: > > I prefer (2) > >> On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wrote: >> >> On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >>> 1. Use the same key for

Re: [TLS] Consensus call for keys used in handshake and data messages

On 13 June 2016 at 21:27, Daniel Kahn Gillmor wrote: > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> > > or >> >> 2. Restore a public content type and different keys

Re: [TLS] Consensus call for keys used in handshake and data messages

> On 13 Jun 2016, at 10:00 PM, Joseph Salowey wrote: > > For background please see [1]. > > Please respond to this message indicating which of the following options you > prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in

Re: [TLS] Consensus call for keys used in handshake and data messages

I prefer option 1. Cheers, Andrei From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Joseph Salowey Sent: Monday, June 13, 2016 12:00 PM To: tls@ietf.org Subject: [TLS] Consensus call for keys used in handshake and data messages For background please see [1]. Please respond to this message

Re: [TLS] Consensus call for keys used in handshake and data messages

I prefer (2) > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor wrote: > > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: >> 1. Use the same key for handshake and application traffic (as in the >> current draft-13) >> >> or >> >> 2. Restore a public content type

Re: [TLS] Consensus call for keys used in handshake and data messages

+1 On Mon, Jun 13, 2016 at 9:27 PM, Daniel Kahn Gillmor wrote: > On Mon 2016-06-13 15:00:03 -0400, Joseph Salowey wrote: > > 1. Use the same key for handshake and application traffic (as in the > > current draft-13) > > > > or > > > > 2. Restore a public content type