[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-01.txt
From: "Christopher Wood" <caw () heapingbits ! net>
Date: 2019-06-08 13:33:31
Message-ID: be82d082-afb2-4a22-9383-5529e25ea48a () www ! fastmail ! com
[Download RAW message or body]
Thanks for the comments, Hubert! Please see inline below.
On Fri, Jun 7, 2019, at 4:37 AM, Hubert Kario wrote:
> On Friday, 7 June 2019 01:47:25 CEST internet-drafts@ietf.org wrote:
> > There are also htmlized versions available at:
> > https://tools.ietf.org/html/draft-ietf-tls-ticketrequests-01
>
> > clients without server-side, per-client state. Servers vend an
>
> > number of tickets vended per connection. Second, clients do not have
>
> > NewSessionTicket messages to vend. This extension is only applicable
>
> > such services to vend tickets to clients to use for accelerated
>
> > A supporting server MAY vend TicketRequestContents.count
>
> > tickets they are willing to vend to clients. Thus, the number of
>
> typos: send, sended
Good catch -- will fix.
> I think that the use cases should list a situation in which the client does
> not expect to perform session resume, so it can inform the server of that by
> sending the value 0.
Good suggestion! We can certainly add this.
> The draft does not state what is the expected behaviour with tickets in
> relation to post-handshake authentication.
As the extension is merely a hint to servers when deciding how many tickets to vend, \
I think this is out of scope for the document.
> The draft does not state if the extension is negotiated once per session or
> its values should be reused for resumed sessions.
It's intended to be once per session, and we'll add that.
> The draft does not state how the extension interacts with Hello Retry Request
> handshake. Can it be dropped/added/changed in 2nd CH message? What is expected
> to happen when client does change it?
Also a good catch. Like other extensions that are not affected by the possibly \
updated ClientHello, it must not change. We need to specify the server side behavior, \
too.
> > Servers that support ticket requests MUST NOT echo "ticket_request"
> > in the EncryptedExtensions.
>
> It's not spelled out what the client is expected to do when server does
> violate this expectation. I'd say it should abort with unsupported_extension.
That seems reasonable to me.
Thanks again for the comments. We'll incorporate them into a next revision ASAP.
Best,
Chris (no hat)
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic