Hello folks,
We'd like to add a field to the KeyUpdate message that represents the
generation of receive traffic keys in use by the sender of the KeyUpdate
message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426)
How this helps: In the current draft, an endpoint that sends a KeyU
On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote:
> Hello folks,
>
> How this helps: In the current draft, an endpoint that sends a KeyUpdate
> message and later receives a KeyUpdate message cannot know whether the
> other side has actually updated its receive keys. The two messages m
On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins wrote:
>>
>> Hi,
>>
>> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
>>> Hi,
>>>
Although the lack of modern cipher-suites for SRP makes it not very
attractive these days.
Hello,
g/html/draft-ietf-tls-pwd-
>> The real
>> problem here is that there is no reason not to use certificates in a
>> lot of cases.
>
> when TLS
> is used to protect non-browser traffic there are plenty of cases
> where you won't have an implicit trust anchor database or you're
> going to som
On Feb 26, 2016 11:26 AM, "Dan Harkins" wrote:
>
>
> On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote:
> > On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins
wrote:
> >>
> >> Hi,
> >>
> >> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
> >>> Hi,
> >>>
> Although the lack of modern
On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd wrote:
> On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk
> wrote:
> > As I said in another email, without client authentication (which is the
> > scenario in the Karthik quote), data sent by the server should be
> considered
> > secure only against p
