On Thu, Jul 7, 2016 at 6:44 AM, Hugo Krawczyk
wrote:
> I do not have an objection to option 1 if re-phrased as
> Option 1 - use the same key for protecting both *post*-handshake and
> applications messages..
>
> I believe this is what was intended by that option anyway. Let me clarify.
>
> I unde
On Jul 8, 2016 6:50 AM, "Joseph Salowey" wrote:
>
> We would like to have all comments in on this by Friday, July 7, 2016.
>
> Also, to clarify, Hugo's interpretation is correct:
>
> Option 1 - use the same key for protecting both *post*-handshake and
applications messages.
I don't object to this
We would like to have all comments in on this by Friday, July 7, 2016.
Also, to clarify, Hugo's interpretation is correct:
Option 1 - use the same key for protecting both *post*-handshake and
applications messages.
On Thu, Jul 7, 2016 at 2:44 AM, Hugo Krawczyk
wrote:
> I do not have an obje
Hi,
After several discussions (including the ones Douglas points out) I have
also come round to option 1 as the preferred way forward. For our symbolic
analysis in Tamarin it should not make a big difference anyway.
Best,
Cas
On Thu, Jul 7, 2016 at 8:47 PM, Douglas Stebila wrote:
> With Hugo
With Hugo's analysis of the secure channel-like security afforded even when the
application key is used to encrypt non-application data, and as Cédric pointed
out to me the application key will be used to encrypt non-application data like
certain alert messages; so I think option 1 is a reasonab
I do not have an objection to option 1 if re-phrased as
Option 1 - use the same key for protecting both *post*-handshake and
applications messages..
I believe this is what was intended by that option anyway. Let me clarify.
I understand the question as relating *only* to post-handshake messages a
On Thu, Jul 07, 2016 at 07:10:20AM +0200, Karthikeyan Bhargavan wrote:
> If we are left with 1 or 3, the miTLS team would prefer 1.
Yeah, me too.
> On the cryptographic side, Hugo has a recent (draft) paper that seems
> to provide some more justification for (1), at least for client
> authenticat
If we are left with 1 or 3, the miTLS team would prefer 1.
On the cryptographic side, Hugo has a recent (draft) paper that seems to provide
some more justification for (1), at least for client authentication.
I know this is a bit off-topic, but the miTLS team would also like to get rid
of 0-RTT
On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote:
> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett
> wrote:
>
>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>> > I'm also curious which post-handshake messages are the problem. If we
>> were
>> > to rename "post-handshake handsha
On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett wrote:
> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> > I'm also curious which post-handshake messages are the problem. If we
> were
> > to rename "post-handshake handshake messages" to "post-handshake bonus
> > messages" with a dist
On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
> I'm also curious which post-handshake messages are the problem. If we were
> to rename "post-handshake handshake messages" to "post-handshake bonus
> messages" with a distinct bonus_message record type, where would there
> still be an
On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote:
> Hi, Joe
>
> > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote:
> >
> > We are the unenviable position of calling consensus between three
> choices [0]:
> >
> > - Option 1 - use the same key for both handshake and applications
> messages.
> > - Opt
Hi, Joe
> On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote:
>
> We are the unenviable position of calling consensus between three choices [0]:
>
> - Option 1 - use the same key for both handshake and applications messages.
> - Option 2 - restore a public content type and different keys.
> - Opti
Hi Joe,
it might be interesting to note that in the context of the DTLS 1.3
discussion with Ilari it appears that the epoch exposes handshake
messages (vs. application data) since you need a way to find out what
key was used to encrypt the message (and msgs may get re-ordered or lost).
So, I clai
We are the unenviable position of calling consensus between three choices
[0]:
- Option 1 - use the same key for both handshake and applications messages.
- Option 2 - restore a public content type and different keys.
- Option 3 - separately encrypting the content type.
At this point the consensu
15 matches
Mail list logo
