On Mon, Jan 4, 2016 at 4:11 PM, Martin Thomson
wrote:
> On 5 January 2016 at 05:03, Eric Rescorla wrote:
> > Ask and ye shall receive:
> http://tlswg.github.io/tls13-spec/#digital-signing
> >
> > "Following that padding is a context string used to disambiguate
> signatures
> > for different purp
On 5 January 2016 at 05:03, Eric Rescorla wrote:
> Ask and ye shall receive: http://tlswg.github.io/tls13-spec/#digital-signing
>
> "Following that padding is a context string used to disambiguate signatures
> for different purposes.
> The context string will be specified whenever a digitally-sign
On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario wrote:
> On Monday 04 January 2016 09:44:57 Eric Rescorla wrote:
> > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario
> wrote:
> > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > > > On Wednesday, December 23, 2015 3:05 PM, Eric Resco
On Monday 04 January 2016 09:44:57 Eric Rescorla wrote:
> On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario
wrote:
> > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> > > >> Similarly, in the HKDF-Expand-Label, do we
> The idea is to make this prefix-free. I added it as an explicit byte but
> would be ok with a different separator as long as we banned it from the
> context strings.
Perhaps explain that rationale in the doc?
___
TLS mailing list
TLS@ietf.org
https:/
On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario wrote:
> On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte
> > >> for the "label"?>
> > > No. I wo
On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte
> >> for the "label"?>
> > No. I wonder if we should instead add the '\0' explicitly in the
> > 4.
Thank you all for your help.
Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360
- Original Message -
From: Roland Zink
To: tls@ietf.org
Sent: Monday, January 4, 2016 8:32 AM
Subject: Re: [TLS] TCP Keep Alive Question: draft-ietf-tls-tls13-11
TCP keep alives are ha
TCP keep alives are handled by the TCP stack and not given to TLS or as
Watson said invisible to TLS.
Roland
Am 04.01.2016 um 16:59 schrieb nalini.elk...@insidethestack.com:
On Mon, Jan 4, 2016 at 7:45 AM, wrote:
Hello All,
Please excuse if this topic has been previously discussed. I hav
On Mon, Jan 4, 2016 at 7:45 AM, wrote:
> Hello All,
>
> Please excuse if this topic has been previously discussed. I have a question
> about TCP Keep Alives.
>
> Section 5 of draft-ietf-tls-tls13-11 reads:
>
> "Three protocols that use the TLS Record Protocol are described in this
> document:
On Mon, Jan 4, 2016 at 7:45 AM, wrote:
>> Hello All,
>>
>> Please excuse if this topic has been previously discussed. I have a
>> question about TCP Keep Alives.
>>
>> Section 5 of draft-ietf-tls-tls13-11 reads:
>>
>> "Three protocols that use the TLS Record Protocol are described in this
>>
Hello All,
Please excuse if this topic has been previously discussed. I have a question
about TCP Keep Alives.
Section 5 of draft-ietf-tls-tls13-11 reads:
"Three protocols that use the TLS Record Protocol are described in this
document: the TLS Handshake Protocol, the Alert Protocol, and the
On 01/04/2016 01:19 PM, Hubert Kario wrote:
>> Dealing with this during the initial handshake is fine. But
>> supporting direction-switching after that is *really* difficult.
>
> yes, this is a bit more problematic, especially for one-sided transfers.
> For example, when one side is just sendin
On Monday 04 January 2016 13:02:57 Florian Weimer wrote:
> On 01/04/2016 12:59 PM, Hubert Kario wrote:
> > On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> >> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> >>> if the rekey doesn't allow the application to change
> >>> authentication
> >>>
On 12/28/2015 10:09 PM, Salz, Rich wrote:
>> When the key is changed, the change procedure should involve new randomness.
>
> I don't think this is necessary, and I don't think the common crypto
> expertise agrees with you, either. But I am not a cryptographer, maybe one of
> the ones on this l
On 01/04/2016 12:59 PM, Hubert Kario wrote:
> On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
>> On 12/21/2015 01:41 PM, Hubert Kario wrote:
>>> if the rekey doesn't allow the application to change authentication
>>> tokens (as it now stands), then rekey is much more secure than
>>> reneg
On Monday 28 December 2015 21:08:10 Florian Weimer wrote:
> On 12/21/2015 01:41 PM, Hubert Kario wrote:
> > if the rekey doesn't allow the application to change authentication
> > tokens (as it now stands), then rekey is much more secure than
> > renegotiation was in TLS <= 1.2
>
> You still have
17 matches
Mail list logo
