On Sat, Nov 16, 2019 at 03:59:53PM -0800, Benjamin Kaduk wrote:
> > That also works, effectively treat 0xff as "-1", but all other
> > values as non-negative, with 0 a request for re-use. An isomorphic
> > encoding, but without the "-1".
>
> [Jeremy had a more eloquent description of the vague
On Sat, Nov 16, 2019 at 04:06:17PM -0500, Viktor Dukhovni wrote:
> On Sat, Nov 16, 2019 at 04:38:17PM +, Jeremy Harris wrote:
>
> > > Do you have an alternative suggestion?
> >
> > The obvious encoding to me would be to reserve the all-bits-set value
> > to mean "client wants no tickets",
On Sat, Nov 16, 2019 at 04:38:17PM +, Jeremy Harris wrote:
> > Do you have an alternative suggestion?
>
> The obvious encoding to me would be to reserve the all-bits-set value
> to mean "client wants no tickets", all-bits-clear to mean "client
> prefers to reuse tickets", anything else
On 16/11/2019 11:04, Viktor Dukhovni wrote:
>> We should probably be emphasizing that *all* policy belongs on the server,
>> and
>> we are just defining a signal for the client to convey some information as
>> input
>> to the server's decision. In that mindset I'm not sure that the "subtract
On Sat, Nov 16, 2019 at 02:38:55AM -0800, Benjamin Kaduk wrote:
> > The -03 draft added a sentence suggesting that clients should ask for
> > just
> > one ticket on resumption, but I would like to suggest that this logic
> > belongs in the server.
>
> We should probably be
On Sat, Nov 16, 2019 at 05:05:46AM -0500, Viktor Dukhovni wrote:
> On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote:
>
> > The only comment that was not integrated was the desire to use the hint
> > to express not only a count, but also a bit indicating whether or not
> > clients
On Thu, Nov 14, 2019 at 08:05:34AM -0800, Christopher Wood wrote:
> The only comment that was not integrated was the desire to use the hint
> to express not only a count, but also a bit indicating whether or not
> clients will accept a ticket if the server needs to send one (e.g., if its
> STEK
Hi Hubert,
I do not understand why tickets sent after PHA would be useless. It is also
unclear if not one solution means there are multiple good solutions - in
which case we could pick one - or that there is not one. At least I would
envisioned something around the lines below.
For a given
On Thursday, 14 November 2019 18:18:52 CET, Daniel Migault wrote:
Hi Hubert,
The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
Hi Hubert,
The reason I would prefer the client to enforce the count is that if a
client has constraints - memory / bandwidth, he wants to make sure its
preference is respected, and this independently of the evolution of how the
hint will be interpreted in the future or depending on different
On Thu, Nov 14, 2019, at 8:57 AM, Daniel Migault wrote:
> Unless I am missing something, the text below seems to say otherwise.
> Note: Although the resumption master secret depends on the client's
>second flight, a server which does not request client authentication
>MAY compute the
On Thursday, 14 November 2019 17:19:55 CET, Daniel Migault wrote:
Hi Chris,
Thanks for the responses, please see my comments inline.
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
wrote:
On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
Hi,
The current version
Unless I am missing something, the text below seems to say otherwise.
Note: Although the resumption master secret depends on the client's
second flight, a server which does not request client authentication
MAY compute the remainder of the transcript independently and then
send a
On Thu, Nov 14, 2019, at 8:48 AM, Christopher Wood wrote:
> On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> > If tickets are sent right after the server Finished, before the the
> > client Finished, these are only triggered by the clientHello - at least
> > this is my understanding.
>
On Thu, Nov 14, 2019, at 8:43 AM, Daniel Migault wrote:
> If tickets are sent right after the server Finished, before the the
> client Finished, these are only triggered by the clientHello - at least
> this is my understanding.
Yes, that's correct. I thought your comment was about
Hi,
If tickets are sent right after the server Finished, before the the client
Finished, these are only triggered by the clientHello - at least this is my
understanding.
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:25 AM Christopher Wood
wrote:
>
>
> On Thu, Nov 14, 2019, at 8:19 AM, Daniel
On Thu, Nov 14, 2019, at 8:19 AM, Daniel Migault wrote:
> Hi Chris,
>
> Thanks for the responses, please see my comments inline.
>
> Yours,
> Daniel
>
> On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
> wrote:
> > On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> > > Hi,
> >
Hi Chris,
Thanks for the responses, please see my comments inline.
Yours,
Daniel
On Thu, Nov 14, 2019 at 11:02 AM Christopher Wood
wrote:
> On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> > Hi,
> >
> > The current version is clearer than the previous one. However, as I
> >
On Tue, Nov 5, 2019, at 5:32 PM, Martin Thomson wrote:
> There was a lengthy discussion after the last time this was discussed.
> Can I request that an editor (or a chair) summarize that discussion and
> the resulting actions (if any)? I was involved in that discussion, but
> I don't see any
On Thu, Nov 14, 2019, at 7:50 AM, Daniel Migault wrote:
> Hi,
>
> The current version is clearer than the previous one. However, as I
> understand the document, it still seems very asymmetric in the sense
> that it does not provide the client the ability to enforce a number. I
> believe more
Hi,
The current version is clearer than the previous one. However, as I
understand the document, it still seems very asymmetric in the sense
that it does not provide the client the ability to enforce a number. I
believe more guidances/specifications are needed on how to interpret the
count value.
There was a lengthy discussion after the last time this was discussed. Can I
request that an editor (or a chair) summarize that discussion and the resulting
actions (if any)? I was involved in that discussion, but I don't see any
changes from that. I'm totally OK with publication as-is, but
I read it. I support it. Ship it.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
All,
This is the working group last call for the "TLS Ticket Requests" draft
available at https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/.
Please review the document and send your comments to the list by 2359 UTC on 19
November 2019.
Note the the GH repo for this draft can be
101 - 124 of 124 matches
Mail list logo
