On Fri, Feb 28, 2020 at 11:23:48AM -0500, Sean Turner wrote:
> * Consider the PR: [1]. This PR explains that when racing connections, the
> client will not necessarily know the number of tickets it will “consume”, so
> it should either have enough tickets for two subsequent handshake
> resumpt
Hi Viktor,
I like the editorial changes in your PR #18, as they do a good job of
explaining things.
However, I don't think we should add a second count in this extension.
Allowing ticket
reuse is not something we have consensus for in the WG, and I would like to
see this
discussion happen in the T
On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> I like the editorial changes in your PR #18, as they do a good job of
> explaining things.
Thanks! I could add a bit more text to guide client implementations on
how to update their ticket caches in response to tickets from the
se
On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> However, I don't think we should add a second count in this extension.
> Allowing ticket reuse is not something we have consensus for in the
^^^
Did I miss a consensus call or s
On Sat, Feb 29, 2020 at 2:57 PM Nico Williams wrote:
> On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> > However, I don't think we should add a second count in this extension.
> > Allowing ticket reuse is not something we have consensus for in the
>^^
On Sat, Feb 29, 2020 at 2:28 PM Viktor Dukhovni
wrote:
> But the second count is not just or even primarily for reuse, it is also
> useful for the non-reuse case as explained in the new text. The fact
> that it then possible to cleanly express reuse is a byproduct, and I
> also don't mean to enc
On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
> Furthermore, I still think the topic of reuse is out of scope for
> draft-ietf-tls-ticket-request.
But is not at all out of scope. This extension is negotiating ticket
requirements between client and server. It is not possible fo
On Sat, Feb 29, 2020 at 04:34:17PM -0800, David Schinazi wrote:
> I think that what you bring up here has value, but I do not see it in
> scope of draft-ietf-tls-ticket-request.
I don't see how it can be out of scope. The abstract clearly
puts it in scope:
TLS session tickets enable stateles
My personal opinion is that reuse is clearly out of scope,
especially given the diverging opinions in the working
group on this topic.
I'm going to let the chairs step in and let us know what
their view of the scope is.
David
On Sat, Feb 29, 2020 at 4:50 PM Viktor Dukhovni
wrote:
> On Sat, Feb
On Sat, Feb 29, 2020 at 04:29:38PM -0800, David Schinazi wrote:
> On Sat, Feb 29, 2020 at 2:57 PM Nico Williams wrote:
> > On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> > > However, I don't think we should add a second count in this extension.
> > > Allowing ticket reuse is not
Issues
--
* tlswg/dtls13-spec (+1/-0/💬0)
1 issues created:
- legacy cookie field (by martinthomson)
https://github.com/tlswg/dtls13-spec/issues/118
* tlswg/tls-subcerts (+1/-0/💬0)
1 issues created:
- Editor drafts are out-of-date (by Lekensteyn)
https://github.com/tlswg/tls-sub
11 matches
Mail list logo
