Hi Hubert, I agree. Yours, Daniel
On Fri, Oct 4, 2019 at 9:17 AM Hubert Kario <hka...@redhat.com> wrote: > On Thursday, 3 October 2019 22:15:14 CEST Daniel Migault wrote: > > On Thu, Oct 3, 2019 at 7:56 AM Hubert Kario <hka...@redhat.com> 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 stated and indication to chose an appropriated > > > > > > value > > > > > > > for each cases may be provided. > > > > > > > > I would rather see the count value as a hard line from the server > with a > > > > MUST NOT instead of a SHOULD NOT statement. > > > > > > see my previous comments: this ignores existence of post handshake > > > authentication, ticket lifetimes and KeyUpdate > > > > I think we agree on the problem which is it is hard to have a specific > > count as tickets may be sent at multiple time during the key exchange or > > the later during the session. If the "SHOULD" is addressing this aspect I > > believe that more text is needed.. From my perspective, what I proposed > I > > imagined that count was related to the maximum number of ticket provided > > **each time the server is sending tickets**. The reason for having the > same > > number is that the server does not know how the client will use these > > tickets and the client does not know precisely when the server sends the > > tickets. So at the end the number of tickets sent is likely to be n*count > > when n represents the number of times during the session tickets are > > provided. > > > > My understanding of the SHOULD is that it makes legitimate for a server > to > > ignore the count value provided by the client. > > yes, it looks like we are in agreement > > Sounds like something that should be spelled out explicitly in the draft. > I.e. > it should talk about groups of tickets, not tickets in connection, and it > should definitely not specify the maximum number of tickets a server can > send > in a connection. > > > > > The ability to request 255 tickets with one byte can be seen as an > > > > amplification vector, especially when a server sends directly the > > > > tickets > > > > after its Finished message. I believe that additional text in the > > > > > > security > > > > > > > consideration could be added. > > > > > > true > > > > > > > Yours, > > > > Daniel > > > > > > > > On Tue, Oct 1, 2019 at 1:27 PM Christopher Wood <c...@heapingbits.net > > > > > > > > wrote: > > > > > 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 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 be kept as part of session and impacts > > > > > > > > > > connections > > > > > > > > > > > > > that perform resumption? > > > > > > > > > > > > > > Sorry, I meant connection: > > > > > > > "Clients may indicate to servers their desired number of > > > > > > > tickets > > > > > > > > > > for *a > > > > > > > > > > > > single connection* via the following "ticket_request" > extension" > > > > > > > > > > > > > > This is a simple hint for servers. Nothing more. No state > needs to > > > > > > be > > > > > > > > stored > > > > > > > > > > > > past connection establishment. > > > > > > > > > > > > sounds good > > > > > > > > > > > > > > > > what's the expected behaviour with tickets and > > > > > > > > > > post-handshake > > > > > > > > > > authentication? Are tickets sent after PHA also bound by > > > > > > > > > > this > > > > > > > > > > limit? > > > > > > > > > > > > > > As mentioned earlier, there is no effect, so we left it > out. > > > > > > We're > > > > > > > > happy > > > > > > > > > > > > > > to > > > > > > > > > accept text should you think it's needed. > > > > > > > > > > > > > > > > If the I-D states that servers should not send more tickets > than > > > > > > the > > > > > > > > > > > client > > > > > > > > asked for, and then send exactly that amount, then they > won't be > > > > > > > > > > able to > > > > > > > > > > > > > send new tickets after PHA and remain compliant. > > > > > > > > > > > > > > > > Yes, it's completely up to the server to decide if to send > > > > > > tickets > > > > > > > > after > > > > > > > > > > > > > PHA or not, and I'm not suggesting that the client should > > > > > > > > request > > > > > > > > for > > > > > > > > tickets in one of its PHA messages, much less expect or > require > > > > > > > > > > them, but > > > > > > > > > > > > > sending tickets after PHA is reasonable and explicitly stated > > > > > > > > > > behaviour: > > > > > > > > RFC 8446 Section 4.6.1: > > > > > > > > For instance, the server might send a new > > > > > > > > ticket after post-handshake authentication in order to > > > > > > > > encapsulate > > > > > > > > the additional client authentication state. > > > > > > > > > > > > > > > > so the I-D should explicitly state what's the expected > behaviour > > > > > > in > > > > > > > > that > > > > > > > > > > > > > case. > > > > > > > > > > > > > > > > IMHO, the extension should be used for the tickets sent right > > > > > > after > > > > > > > > the > > > > > > > > > > > > > handshake, it should not put an upper bound for the tickets > that > > > > > > a > > > > > > > > server > > > > > > > > > > > > > can send in a single connection. For a very long lived > > > > > > > > connection > > > > > > > > (especially if the connection uses KeyUpdate messages > > > > > > > > regularly), > > > > > > > > the > > > > > > > > initial tickets may expire. Server may notice that and send a > > > > > > > > new > > > > > > > > > > group > > > > > > > > > > > > > of tickets then. > > > > > > > > > > > > > > Since these hints are not mandatory to honor I don't think we > need > > > > > > to > > > > > > > > > > describe this case. In particular, this is a valid case where > > > > > > ignoring > > > > > > > > the > > > > > > > > > > > > SHOULD is fine, in my opinion. > > > > > > > > > > > > > > If the draft required that servers MUST NOT send more tickets > than > > > > > > > > > > what's > > > > > > > > > > > > requested, then yes, I think these details would be important.. > > > > > > > > > > > > huh? I see the following in the draft-02: > > > > > > Servers MUST NOT > > > > > > send more than 255 tickets to clients. > > > > > > > > > > I was referring to the "SHOULD NOT send more than > > > > > TicketRequestContents.count NewSessionTicket messages" blurb. > Indeed, > > > > > > the > > > > > > > > MUST NOT above should also be a SHOULD NOT. Thanks for your > patience > > > > > in > > > > > working through the kinks! > > > > > > > > > > > -- > > > > > > Regards, > > > > > > Hubert Kario > > > > > > Senior Quality Engineer, QE BaseOS Security team > > > > > > Web: www.cz.redhat.com > > > > > > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic > > > > > > Attachments: > > > > > > * signature.asc > > > > > > > > > > _______________________________________________ > > > > > TLS mailing list > > > > > TLS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > > > Republic_______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech > Republic_______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls