> On Oct 11, 2019, at 4:55 AM, Martin Thomson wrote:
>
> Yeah, I agree that this is a little thorny. However, the client asking for
> one extra and the server vending one more is a relatively small extra expense
> AND we discourage reuse in the general case. So, at least from my
> perspectiv
On Fri, Oct 11, 2019, at 14:07, Viktor Dukhovni wrote:
> * The client has a what it believes to be a valid ticket
> and is willing to re-use it, and would prefer to avoid
> the cost of replacing it on each resumption.
>
> * The server is happy to allow re-use of still valid
> ticke
> On Oct 9, 2019, at 9:04 PM, Martin Thomson wrote:
>
> I think that the discussion Victor started about the number of tickets you
> might want to supply being different for a resumed connection is a sensible
> one, but I would caution against servers making inferences, especially in
> light o
I think that the discussion Victor started about the number of tickets you
might want to supply being different for a resumed connection is a sensible
one, but I would caution against servers making inferences, especially in light
of a very clear signal from clients. Advice for client implement
On Tuesday, 8 October 2019 16:04:18 CEST Daniel Migault wrote:
> If we suppose all tickets are sent by the server at once, I am wondering if
> we have any case where the server will send more tickets that the number
> provided by the hint.
long lasting connection and a ticket encryption key expiri
If we suppose all tickets are sent by the server at once, I am wondering if
we have any case where the server will send more tickets that the number
provided by the hint.
Yours,
Daniel
On Mon, Oct 7, 2019 at 10:46 AM Hubert Kario wrote:
> On Saturday, 5 October 2019 14:08:45 CEST Christopher Wo
On Saturday, 5 October 2019 14:08:45 CEST Christopher Wood wrote:
> On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > > > On Wednesday, 2 October 2019 22:42:32 CEST D
On Sat, Oct 05, 2019 at 05:06:04AM -0700, Christopher Wood wrote:
> > The use-case is clients and servers that don't make use of
> > early-data, and don't need to avoid traffic analysis. For
> > example, MTA-to-MTA traffic, where the client even identifies
> > in clear text with "EHLO". Here tic
On Fri, Oct 4, 2019, at 6:17 AM, Hubert Kario wrote:
> On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > > I understand the meaning of count is the high
On Wed, Oct 2, 2019, at 8:44 PM, Viktor Dukhovni wrote:
> > On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote:
> >
> > Asking for one upon resumption seems reasonable to me. Thanks to you and
> > Viktor for bringing up this case!
>
> Thanks! Much appreciated.
>
> My other point, which I pro
On Thursday, 3 October 2019 05:44:27 CEST Viktor Dukhovni wrote:
> > On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote:
> >
> > Asking for one upon resumption seems reasonable to me. Thanks to you and
> > Viktor for bringing up this case!
> Thanks! Much appreciated.
>
> My other point, which
Hi Hubert,
I agree.
Yours,
Daniel
On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario wrote:
> On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > > I underst
On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote:
> On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> > On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > > I understand the meaning of count is the higher limit of ticket and the
> > > server can provides any tick
On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario wrote:
> On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> > I understand the meaning of count is the higher limit of ticket and the
> > server can provides any tickets between 0 and count. If that is correct,
> > this could be clearly
On 10/01/2019 04:39 AM, Hubert Kario wrote:
On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote:
On 30/09/2019 14:36, Christopher Wood wrote:
On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
Clients must therefore
bound the number of parallel connections they init
On Wednesday, 2 October 2019 22:42:32 CEST Daniel Migault wrote:
> I understand the meaning of count is the higher limit of ticket and the
> server can provides any tickets between 0 and count. If that is correct,
> this could be clearly stated and indication to chose an appropriated value
> for ea
On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood
wrote:
> On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood
> wrote:
> > >
> > > > I understand the meaning of count is the higher limit of ticket and
> the
> > > > server can provides any ticke
> On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote:
>
> Asking for one upon resumption seems reasonable to me. Thanks to you and
> Viktor for bringing up this case!
Thanks! Much appreciated.
My other point, which I probably obscured in too many words, is
that a client that prefers to re-us
On Wed, Oct 2, 2019, at 4:04 PM, Nico Williams wrote:
> On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> > I've read the draft, it looks quite useful and reasonable. It would
> > be good to see this published.
>
> +1
>
> > I have one idea (implemented in OpenSSL 1.1.1 on the se
On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote:
> On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote:
> >
> > > I understand the meaning of count is the higher limit of ticket and the
> > > server can provides any tickets between 0 and count. If that is
> > > correct, this could be clea
On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote:
>
> > I understand the meaning of count is the higher limit of ticket and the
> > server can provides any tickets between 0 and count. If that is
> > correct, this could be clearly stated and indication to chose an
> > appropriated value for
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> I've read the draft, it looks quite useful and reasonable. It would
> be good to see this published.
+1
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and perha
Hi,
Please see my comments.
Yours,
Daniel
On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote:
> Hi Daniel,
>
> Please see inline below.
>
> On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> > Hi,
> >
> > Please find some comments on the draft.
> >
> > In the introduction, I believe bo
Hi Daniel,
Please see inline below.
On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote:
> Hi,
>
> Please find some comments on the draft.
>
> In the introduction, I believe both limitations may be merged into one
> limitation which is the number of ticket is a server only decision. The
>
Hi,
Please find some comments on the draft.
In the introduction, I believe both limitations may be merged into one
limitation which is the number of ticket is a server only decision. The
purpose of the extension is the client providing information so the server
can pick the appropriated number.
On Tue, Oct 1, 2019, at 9:15 AM, Hubert Kario wrote:
> On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> > On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > > ```
> > > > > Servers MUST NOT send more than 255 tickets to clients.
> > > > > ```
> > > > >
> > > > > per w
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote:
> I've read the draft, it looks quite useful and reasonable. It would
> be good to see this published.
>
> I have one idea (implemented in OpenSSL 1.1.1 on the server side)
> that may be worth mentioning in this context (and perhap
On Tuesday, 1 October 2019 16:01:32 CEST Christopher Wood wrote:
> On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > > ```
> > > > Servers MUST NOT send more than 255 tickets to clients.
> > > > ```
> > > >
> > > > per what? session? at a time? connection?
> > >
> > > This is all per ses
On Fri, Sep 27, 2019 at 04:47:16PM -0700, internet-dra...@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title : TLS Ticket Requests
> Au
On Tue, Oct 1, 2019, at 5:18 AM, Hubert Kario wrote:
> > > ```
> > > Servers MUST NOT send more than 255 tickets to clients.
> > > ```
> > >
> > > per what? session? at a time? connection?
> >
> > This is all per session. We can state it explicitly in the next version.
>
> so this count needs to
On Monday, 30 September 2019 15:36:36 CEST Christopher Wood wrote:
> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> > On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> > > This version addresses some of the comments we received from Hubert a
> > > while
> > > back. We
On Monday, 30 September 2019 15:56:19 CEST Jeremy Harris wrote:
> On 30/09/2019 14:36, Christopher Wood wrote:
> > On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> >> Clients must therefore
> >> bound the number of parallel connections they initiate by the
> >> number of ti
On 30/09/2019 14:36, Christopher Wood wrote:
> On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
>> Clients must therefore
>> bound the number of parallel connections they initiate by the
>> number of tickets in their possession, or risk ticket re-use.
>> ```
>>
>> I'm not a
On Mon, Sep 30, 2019, at 6:28 AM, Hubert Kario wrote:
> On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> > This version addresses some of the comments we received from Hubert a while
> > back. We think it's ready to go for WGLC, modulo whatever nits folks find.
> > :-)
>
> I
On Saturday, 28 September 2019 01:59:42 CEST Christopher Wood wrote:
> This version addresses some of the comments we received from Hubert a while
> back. We think it's ready to go for WGLC, modulo whatever nits folks find.
> :-)
I still see the "vend" instead of "send" typos... Same for "vended"
This version addresses some of the comments we received from Hubert a while
back. We think it's ready to go for WGLC, modulo whatever nits folks find. :-)
Best,
Chris (no hat)
On Fri, Sep 27, 2019, at 4:47 PM, internet-dra...@ietf.org wrote:
>
> A New Internet-Draft is available from the on-lin
36 matches
Mail list logo
