I'm not seeing a lot of enthusiasm for this option either.
Do any of the people who were in favor of #1 or #2 want to say they prefer
some variant of this proposal?
-Ekr
On Mon, Jun 20, 2016 at 5:39 PM, Eric Rescorla wrote:
> Nobody seems super-excited about either Option 1 or Option 2, so it
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 s
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 suggested
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 we're going to us
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
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
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 talk
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" (without assumptions known
>to be false or cause severe problems
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 to trade these things off against each
>> other here, but ther
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 they
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 changin
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 an
On Tuesday, June 14, 2016 04:37:09 am Martin Thomson wrote:
> 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
> > >
> >
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 option
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 Monday June, 20, 2016
> >
>
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 dra
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 w
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 and
> handshake is harmful. That question is mainly low level crypto and cou
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, 20, 2016
>>
>> 1.
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, 20, 2016
>
> 1. Use the same key for handshake and application traffic (as in the
> current draft-13
] 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
HO 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
> Subject: Re: [TLS] Consensus call for keys
+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
> miss.
>
> >
> > > On 13 Jun 2016, at 22:27, Daniel K
I am in favour of option (2).
Cheers
Ben.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
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 authenti
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) h
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 foc
On 13/06/2016 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
>
> Given this choice, i prefe
On Tue, Jun 14, 2016 at 1:22 PM, 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
> miss.
Same here. I also find it unlikely that (1) actually has any
significant p
f.org
Subject: 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
On Jun 13, 2016 10:08 PM, "Karthikeyan Bhargavan" <
karthik.bharga...@gmail.com> wrote:
>
> I prefer (2)
Same. It's clear 1 makes proofs more complicated, making mistakes easier to
miss.
>
> > On 13 Jun 2016, at 22:27, Daniel Kahn Gillmor
wrote:
> >
> > On Mon 2016-06-13 15:00:03 -0400, Joseph S
+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 handshake and application traffic (as in the
>>> current draf
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
>
> Given this choice, i
> 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 the current
> draft
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 i
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 and different keys
>
> G
+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 and different keys
>
> Give
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
Given this choice, i prefer (1).
--dkg
38 matches
Mail list logo
