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)
or
2. Restore a public content type and different keys
Thanks,
J&S
Hubert Kario writes:
>run _everything_ is not really possible as some tests actually require
>mutually exclusive server settings - e.g. some require the server not to ask
>for client certificate while others do
Ah, OK.
>finally, while I do look forward to any contributions (just ideas for tests
Hubert Kario writes:
>to be pedantic, the RFC describes itself "a profile" while in reality it
>modifies the protocol in a way that will make it incompatible with "vanilla"
>TLS 1.2 implementations
>to be pedantic, the RFC describes itself "a profile" while in reality it
>modifies the protocol i
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
+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
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
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
