On 24 May 2016 at 19:06, Kyle Nekritz wrote:
> What is the rationale for restricting a change in certificate? If the server
> has a new certificate that the client would accept with a full handshake,
> what threat is added by also accepting that certificate with a PSK handshake?
This was a requ
What is the rationale for restricting a change in certificate? If the server
has a new certificate that the client would accept with a full handshake, what
threat is added by also accepting that certificate with a PSK handshake?
Requiring the certificate to remain the same will make rollout of a
Version -13 includes neither the word "stateful" nor "stateless", so if
Yaron's proposal is taken, it would be better to explicitly refer to
session tickets or ID-based resumption (with appropriate citations).
That said, I'm not sure I see the need for a normative requirement on
the server; we cou
If that is what you are worried about, then that would make sense.
Quynh.
On May 24, 2016 4:23 PM, "Eric Rescorla" wrote:
> No, a smaller computation (say 2^{64}) and then collecting 2^{40}
> connections all of which encipher the same plaintext (e.g., "GET /...")
>
> -Ekr
>
>
> On Tue, May 24, 2
On 20 May 2016 at 12:41, Ilari Liusvaara wrote:
> On Wed, May 18, 2016 at 10:10:29AM -0400, Martin Thomson wrote:
>> I just posted this:
>>
>> https://datatracker.ietf.org/doc/draft-thomson-tls-0rtt-and-certs/
>>
>> It's fairly self explanatory. The idea is to create a way to signal
>> that the c
No, a smaller computation (say 2^{64}) and then collecting 2^{40}
connections all of which encipher the same plaintext (e.g., "GET /...")
-Ekr
On Tue, May 24, 2016 at 1:13 PM, Quynh Dang wrote:
> Are you worried about 2^96 precomputation and the risk of 1/2^32 of
> cracking your key?
>
> Quynh
Are you worried about 2^96 precomputation and the risk of 1/2^32 of
cracking your key?
Quynh.
On May 24, 2016 3:05 PM, "Eric Rescorla" wrote:
>
>
> On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed)
> wrote:
>
>>
>>
>> On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>>
>> >On 24 May 2016 at 10:4
On Tue, May 24, 2016 at 12:00 PM, Dang, Quynh (Fed)
wrote:
>
>
> On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>
> >On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
> >>>We discussed this at quite some length. I originally took your
> >>>position, but the IVs add an extra layer of safety at ve
On 5/24/16, 2:42 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
>>>We discussed this at quite some length. I originally took your
>>>position, but the IVs add an extra layer of safety at very little
>>>cost.
>>
>> I don¹t see any extra layer here.
>
>
>The argu
On 24 May 2016 at 10:46, Dang, Quynh (Fed) wrote:
>>We discussed this at quite some length. I originally took your
>>position, but the IVs add an extra layer of safety at very little
>>cost.
>
> I don¹t see any extra layer here.
The argument here is that there are only 2^128 keys and some proto
On Tue, May 24, 2016 at 10:44:15AM -0700, Colm MacCárthaigh wrote:
> On Tue, May 24, 2016 at 9:13 AM, Martin Thomson
> wrote:
>
> > > 3. "The padded sequence number is XORed with the static client_write_iv
> > or
> > > server_write_iv, depending on the role.” I think the ivs are not needed.
> >
>
On 5/24/16, 12:58 PM, "ilariliusva...@welho.com on behalf of Ilari
Liusvaara" wrote:
>On Tue, May 24, 2016 at 03:20:17PM +, Dang, Quynh (Fed) wrote:
>> Hi Eric,
>>
>> 1. For this text: "plus the length of the output of the signing
>> algorithm. " in the last paragraph of Section 4.8.1, di
On 5/24/16, 12:13 PM, "Martin Thomson" wrote:
>On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote:
>> 1. For this text: "plus the length of the output of the signing
>>algorithm.
>> " in the last paragraph of Section 4.8.1, did you mean "plus the output
>>of
>> the signing algorithm.² ?
>
>The
On Tue, May 24, 2016 at 9:13 AM, Martin Thomson
wrote:
> > 3. "The padded sequence number is XORed with the static client_write_iv
> or
> > server_write_iv, depending on the role.” I think the ivs are not needed.
>
> We discussed this at quite some length. I originally took your
> position, but
On Tue, May 24, 2016 at 03:20:17PM +, Dang, Quynh (Fed) wrote:
> Hi Eric,
>
> 1. For this text: "plus the length of the output of the signing
> algorithm. " in the last paragraph of Section 4.8.1, did you mean
> "plus the output of the signing algorithm." ?
The paragraph seems to talk about
On 24 May 2016 at 08:20, Dang, Quynh (Fed) wrote:
> 1. For this text: "plus the length of the output of the signing algorithm.
> " in the last paragraph of Section 4.8.1, did you mean "plus the output of
> the signing algorithm.” ?
The text is correct. It is talking about the length of the stru
Hi Eric,
1. For this text: "plus the length of the output of the signing algorithm. "
in the last paragraph of Section 4.8.1, did you mean "plus the output of the
signing algorithm." ?
2. "The length (in bytes) of the following TLSCiphertext.fragment. The length
MUST NOT exceed 2^14 + 256. An
17 matches
Mail list logo
