Hi all, I've just published draft-misell-quic-bdp-token-00 <https://datatracker.ietf.org/doc/draft-misell-quic-bdp-token/> as a rough first draft of this concept.
Thanks, Q Misell ------------------------------ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 15 Nov 2023 at 15:40, Q Misell <[email protected]> wrote: > > Hi all, > > I've had a think and some discussion with others about what's been said in > this chain, here are my thoughts. > > > I think I tend to agree with Lucas modulo the point that it would make > more sense to store BDP information in tokens issued by the QUIC servers[1] > than the TLS session ticket. > > The NEW_TOKEN frame would indeed be a very neat way to handle things. > However given that it is opaque this would stop the client from assessing > if it wants to use a token in cases where it is known the BDP has changed > significantly. > > There is one other issue I see with this in that section 8.1.3 says: > "Though saving and using older tokens have no negative consequences, > clients can regard older tokens as being less likely to be useful to the > server for address validation." > An old BDP calculation may have negative consequences, however this could > be mitigated by expiring the BDP calculations in tokens after a certain > time. I'd like some more input on what's the best option here. > > > The BDP_FRAME frame can only be sent in 0-RTT packets (if I understand > correctly, I'm very confused by the phrasing of section 4), so it can’t be > used for non-0-RTT session resumption. > > Agreed that this section needs work on wording. I also think BDP should be > allowed in 0-RTT and 1-RTT, although it provides more value in 0-RTT than > 1-RTT. Allowing 1-RTT BDP also precludes using TLS session resumption > tokens to store BDP data. > > > From a protocol deployability perspective, we should expect that larger > fleets of servers will be wanting to run multivariate testing of CCs in a > way that doesn't require any coordination with the peer. > > This is an excellent point. Might I suggest a compromise[1] in which some > CC parameters are made available to the client to aid in deciding whether > to use a BDP calculation on resumption. The server can signal to the client > that its tokens are encoded with a well-known format akin to the below > using a new bdp_tokens transport parameter. > > BDP Token { > Address Token Length (i), > Address Token Value (..), > Saved Capacity (i), > Saved RTT (i), > BDP Token Length (i), > BDP Token Value(..) > } > > The Address Token is opaque to the client, as is currently the case. The > Saved Capacity and Saved RTT fields are merely hints to the client to help > it decide if it wants to use the token or not. If it decides it doesn't > want to then it can send the token back with the BDP Token set to zero > length, but still preserving the Address Token. The BDP Token contains > opaque data specific to the congestion control algorithm in use by the > server. It is expected the Address Token and the BDP Token contain > appropriate verification to prevent meddling, using whatever method the > server sees fit. > > If the client is unaware of the bgp_tokens parameter it will treat the > entire token as an opaque blob, achieving its intended purpose of > remembering BDP information without client modification. > > I will find some time to write an I-D on this fleshing out the details a > bit more. > > Thanks, > Q Misell > > [1]: compromise, noun: leaving all parties disgruntled; > https://youtu.be/J1Yv24cM2os?t=100 <https://youtu.be/J1Yv24cM2os?t=100> > ------------------------------ > > Any statements contained in this email are personal to the author and are > not necessarily the statements of the company unless specifically stated. > AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, > Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company > registered in Wales under № 12417574 > <https://find-and-update.company-information.service.gov.uk/company/12417574>, > LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 > <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. > EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: > 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru > maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca > Digital, is a company registered in Estonia under № 16755226. Estonian VAT > №: EE102625532. Glauca Digital and the Glauca logo are registered > trademarks in the UK, under № UK00003718474 and № UK00003718468, > respectively. > > > On Mon, 6 Nov 2023 at 17:55, Kazuho Oku <[email protected]> wrote: > >> >> >> 2023年11月6日(月) 13:38 Gorry Fairhurst <[email protected]>: >> >>> See below: >>> >>> On 06/11/2023 10:59, Kazuho Oku wrote: >>> >>> >>> >>> 2023年11月6日(月) 10:08 Gorry Fairhurst <[email protected]>: >>> >>>> On 05/11/2023 15:49, Kazuho Oku wrote: >>>> >>>> >>>> >>>> 2023年11月5日(日) 16:41 Marten Seemann <[email protected]>: >>>> >>>>> > On different CC's: the set of parameters exchanged are fairly >>>>> generic, and I think it's very likely a client will use the same CC to >>>>> talk >>>>> to the same server when it next resumes a session, so I am unsure i share >>>>> the concern about different CCs. >>>>> >>>>> Gorry, I might be misreading the draft, but in my understanding the >>>>> BDP_FRAME frame is used by servers to offload state to the client, not the >>>>> other way around, so your argument should be that the server will use the >>>>> same CC on the original and the resumed connection. The client might also >>>>> remember CC parameters, but they wouldn't be sent on the wire. >>>>> My argument here is twofold: If this frame is supposed to be read and >>>>> acted upon by the client, you now have to deal with the situation where >>>>> client and server use different CCs, which will lead to problems if server >>>>> and client don't use the same CC. On the other hand, if the frame is not >>>>> supposed to be acted upon by the client, there's no reason to use a frame >>>>> in the first place, as servers can just unilaterally decide to put the >>>>> information into the token. >>>>> >>>> >>>> FWIW, in case of quicly I'm not sure we'd want to use CWND and current >>>> RTT to calculate the jump CWND. >>>> >>>> >>>> That is because quicly has a delivery rate estimate based on ACK clock >>>> that gives us a better estimation of the available bandwidth; we'd prefer >>>> using that and the min RTT. >>>> >>>> Sure. This makes this interesting, and I know that ACK'ed rate can have >>>> advantages. >>>> >>>> >>>> As such, I'm not sure if having a standard definition of a BDP frame >>>> would help server implementers. >>>> >>>> I don't agree (yet?) The CC params that are used are to characterise >>>> the path, and have two roles - to enable "reconnaisance" in CR and to >>>> decide upon the unvalidate jump size. This needs at least a saved RTT >>>> value and a rate/window. >>>> >>>> While I agree using rate is different to cwnd, for this specific >>>> purpose, isn't it possible to simply used saved cwnd = rate*RTT? II think >>>> we might be able to agree on parameters for this specific use. >>>> >>> The problem is that the kind of RTT that we want to choose can be >>> different depending on if we have ack clock or if we rely on CWND. >>> >>> When ack clock is available, it would make sense to use idle RTT, >>> because that resembles the state of connection when we are not sending much >>> data (i.e., at the beginning of the connection). I think we should be >>> comparing the previous idle RTT and the new initial RTT in this case. >>> >>> Right, this seems fine. This is why we called it "capacity" ... in >>> recent drafts, let's agreee on a term for the next rev! >>> >>> >>> But when relying on CWND, it would make more sense to send SRTT, CWND >>> changes depending on the size of the bottleneck buffer as well. >>> >>> Also, because CWND is an unconfirmed estimate of the path, it can be 2x >>> as large (at the end of slow start), calculation of CR has to be more >>> conservative than when jumping based on the ack clock. >>> >>> Sure, so iin observation phase CR stores a "saved_capacity" (if we >>> conbtinue to call it that), which ought toi be calculated in the correct >>> way by the sender to measure the capacity. We have some text in the Careful >>> Resume text to say this ought to not include over buffering or data-limited >>> moments - if people think it useful, we can certainly add more text for >>> scenarios using different CCs. (We haven't yet, because the CC saving the >>> params, is in most cases the CC using the params for CR.) >>> >>> To summarize, even though we can send CWND and RTT in both cases, what >>> they mean and how they should be used are going to be different. >>> >>> When the semantics (i.e., meaning and usage) is going to be different, >>> I'm not sure if there is a reason to standardize an encoding. >>> >>> Again though, this "saved_capacity" is used just to make a jump. If we >>> make this value readable to the client to help inform things, it is just a >>> "value" from the server that it will use to compute the jump ... >>> >> >> If the primary intent is to show the client the jump CWND so that the >> client can make adjustments (e.g., to the flow control credits), I kind of >> wonder if it is the best approach to use the information exchanged in the >> previous session. >> >> I would probably argue that such information should be sent as 0.5 RTT >> data from the server. That information would be more accurate (because it >> can convey what the server *now* thinks), and can take care of the >> non-resuming case as well. >> >> Under the current form of CR that requires one RT before the jump, it's >> only the large scale servers that have the need to store the information >> from the previous session. >> >> FWIW, the other benefit that I see of using tokens is that we can add >>> arbitrary data associated to the values used by CRs. Tokens already have >>> the client IP address and time of the previous connection. To observe how >>> well CR works under various conditions, I think we'd put anything we want >>> to the Token and see if there would be correlations / anomalies. >>> >>> +1 >>> >>> In other words, the format of the Tokens would evolve. That's the other >>> reason I am not interested in standardizing what to send. >>> >>> +1 >>> >>> Gorry >>> >>> >>>> To paraphrase, I think the question is if there is an appetite for the >>>> WG to define a frame solely for communicating the estimate of the >>>> unvalidated phase *to the client,* and if sending that at the end of the >>>> previous connection is the best way to do so. >>>> >>>> Good questions. >>>> >>>> Gorry >>>> >>>> >>>> >>>>> >>>>> On Sun, 5 Nov 2023 at 15:32, Gorry Fairhurst <[email protected]> >>>>> wrote: >>>>> >>>>>> On 05/11/2023 10:04, Marten Seemann wrote: >>>>>> >>>>>> In the design of RFC 9000, frames are used to communicate information >>>>>> between two endpoints. This is not what the BDP_FRAME frame does: It's >>>>>> only >>>>>> saved by the client and echoed back to the server on a later connection. >>>>>> It >>>>>> is questionable to me if the client’s ability to inspect (but not modify) >>>>>> the contents of the frame provides a lot of value: Congestion controllers >>>>>> are inherently endpoint-specific, and (for example) reusing the >>>>>> parameters >>>>>> of an L4S CC with a Cubic CC, and vice versa, doesn't sound like a good >>>>>> idea. >>>>>> >>>>>> That's not what the ID says. >>>>>> >>>>>> On different CC's: the set of parameters exchanged are fairly >>>>>> generic, and I think it's very likely a client will use the same CC to >>>>>> talk >>>>>> to the same server when it next resumes a session, so I am unsure i share >>>>>> the concern about different CCs. >>>>>> >>>>>> Section 1.2 of the ID speaks about the possibility to share the >>>>>> infromation with the application... which might be important to tuning >>>>>> the >>>>>> use of the token (choosing which connection ought to use the >>>>>> Careful-Resume), and ensuring appropriate polices are used for >>>>>> flow-credit, >>>>>> choosing content encoding appropriate to rate, etc. >>>>>> >>>>>> >>>>>> As Kazuho pointed out, RFC 9000 already contains the concept of a >>>>>> resumption token. >>>>>> >>>>>> I'd like to understand more what that is. >>>>>> >>>>>> Tokens are opaque, so servers can encode whatever information they >>>>>> want into the token. Resumption tokens are used to validate the client’s >>>>>> IP >>>>>> address, so they’re inherently bound to the path. This is pretty much >>>>>> exactly the property that you’d want for resuming CC parameters. Apart >>>>>> from >>>>>> that, using tokens has multiple other advantages as well: >>>>>> 1. We don’t need interoperability between implementations here. The >>>>>> client is resuming the connection with the same server (or a different >>>>>> server in the same deployment), so it doesn’t matter how the information >>>>>> is >>>>>> encoded. >>>>>> >>>>>> I like that. >>>>>> >>>>>> 2. Depending on their CC, servers might want to encode a different >>>>>> set of parameters. This is possible when using a token, whereas the >>>>>> BDP_FRAME frame limits us to the few fields defined in the draft. >>>>>> >>>>>> Good - but I do expect that a BDP_FRAME could be made extensible. >>>>>> >>>>>> 3. The BDP_FRAME frame can only be sent in 0-RTT packets (if I >>>>>> understand correctly, I'm very confused by the phrasing of section 4), so >>>>>> it can’t be used for non-0-RTT session resumption. >>>>>> >>>>>> I think that depends a little on how we decide to finally transport >>>>>> the parms - we're open to changing this. >>>>>> >>>>>> 4. Obviously, using the token doesn’t require clients to be aware >>>>>> that this is going on, so it will work with every QUIC stack without any >>>>>> modification. >>>>>> >>>>>> Yes, that's nice also. >>>>>> >>>>>> Best wishes, >>>>>> >>>>>> Gorry >>>>>> >>>>>> >>>>>> >>>>>> On Sun, 5 Nov 2023 at 11:14, Kazuho Oku <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> 2023年11月4日(土) 15:44 <[email protected]>: >>>>>>> >>>>>>>> BDP frame is about QUIC transport (RFC9000) resumption. IMO, it >>>>>>>> does not have dependencies on RFC9001. >>>>>>>> >>>>>>> >>>>>>> I think I tend to agree with Lucas modulo the point that it would >>>>>>> make more sense to store BDP information in tokens issued by the QUIC >>>>>>> servers[1] than the TLS session ticket. >>>>>>> >>>>>>> Tokens are defined in RFC 9000. The only use case being mandated at >>>>>>> the moment is address validation but it is designed so that it can hold >>>>>>> arbitrary data. Tokens can hold BDP information as well. >>>>>>> >>>>>>> 1: https://datatracker.ietf.org/doc/html/rfc9000#frame-new-token >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Orange Restricted >>>>>>>> >>>>>>>> *De :* Gorry Fairhurst <[email protected]> >>>>>>>> *Envoyé :* samedi 4 novembre 2023 14:45 >>>>>>>> *À :* STEPHAN Emile INNOV/NET <[email protected]>; Nicolas >>>>>>>> Kuhn <[email protected]>; [email protected] >>>>>>>> *Objet :* Re: Authentication in draft-kuhn-quic-bdpframe-extension >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 04/11/2023 13:28, [email protected] wrote: >>>>>>>> >>>>>>>> Hi >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> IMO, we are speaking of QUIC resumption not TLS. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> Emile >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I think QUIC CC resumption could be a part of TLS resumption. Are >>>>>>>> there also cases where these could be different things? >>>>>>>> >>>>>>>> Gorry >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *De :* QUIC <[email protected]> <[email protected]> *De la >>>>>>>> part de* Nicolas Kuhn >>>>>>>> *Envoyé :* samedi 4 novembre 2023 12:43 >>>>>>>> *À :* [email protected] >>>>>>>> *Objet :* Re: Authentication in draft-kuhn-quic-bdpframe-extension >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Dear all, >>>>>>>> >>>>>>>> Thank you for your interest in this work ! >>>>>>>> >>>>>>>> I would tend to agree with Lucas and think we should consider >>>>>>>> scenarios where BDP frames would be used with TLS resumption and I do >>>>>>>> not >>>>>>>> see the need for proposing another trust mechanism; But there may be >>>>>>>> scenarios I do not see ? >>>>>>>> >>>>>>>> More comments inline. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> >>>>>>>> Nico >>>>>>>> >>>>>>>> On 11/3/23 16:44, Lucas Pardue wrote: >>>>>>>> >>>>>>>> Hi folks, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I'm still trying to come up to speed on this spec. But when I've >>>>>>>> thought about it a little, its seemed very natural to associate the BDP >>>>>>>> frame (contents) with the TLS session. We already have a lot of text >>>>>>>> about >>>>>>>> TLS session resumption in QUIC. It feels like there is already a >>>>>>>> template >>>>>>>> design with HTTP/3 - a server sends SETTINGS to tell a client something >>>>>>>> unique about the active QUIC connection. RFC 9114 section 7.2.4.2 >>>>>>>> [1]states >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > When a 0-RTT QUIC connection is being used, the initial value of >>>>>>>> each server setting is the value used in the previous session. Clients >>>>>>>> *SHOULD* store the settings the server provided in the HTTP/3 >>>>>>>> connection where resumption information was provided, but they >>>>>>>> *MAY* opt not to store settings in certain cases (e.g., if the >>>>>>>> session ticket is received before the SETTINGS frame). A client >>>>>>>> *MUST* comply with stored settings -- or default values if no >>>>>>>> values are stored -- when attempting 0-RTT. Once a server has provided >>>>>>>> new >>>>>>>> settings, clients *MUST* comply with those values.¶ >>>>>>>> <https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.2-6> >>>>>>>> >>>>>>>> So with a bit of massaging, if we can link BDP frame to session >>>>>>>> resumption. we know that it is based on a previous trust relationship. >>>>>>>> >>>>>>>> Is there any scenario where BDP frame would want to be used without >>>>>>>> TLS resumption? >>>>>>>> >>>>>>>> [NK] I agree. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers >>>>>>>> >>>>>>>> Lucas >>>>>>>> >>>>>>>> >>>>>>>> [1] - https://www.rfc-editor.org/rfc/rfc9114.html#section-7.2.4.2-6 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Nov 2, 2023 at 6:17 PM Gorry Fairhurst < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> On 02/11/2023 16:43, Q Misell wrote: >>>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I've been working with Gorry (and others) on actually implementing >>>>>>>> the BDP frame extension, and further refining the draft based on >>>>>>>> experience >>>>>>>> from implementation. >>>>>>>> >>>>>>>> Q, I think I can help a little, see below, but I think there are >>>>>>>> good questions here. >>>>>>>> >>>>>>>> [NK] If the draft is not clear enough on these relevant questions, >>>>>>>> we ought to make things clearer. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> One thing that came up that I'd like to ask the WG's opinion on is >>>>>>>> that of authentication of the BDP frame, and when it should be sent in >>>>>>>> the >>>>>>>> exchange. I've had a few thoughts on this, it'd be great to hear what >>>>>>>> others think of them, or what other suggestions people might have. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> First, my thoughts on authentication. Do the CC parameters need to >>>>>>>> be authenticated at all? I would say "yes" as a client sending some >>>>>>>> unauthenticated CC parameters could cause a DoS of the server (or any >>>>>>>> other >>>>>>>> node along the path) by trying to send far too much data at once. >>>>>>>> >>>>>>>> The reason for the secure hash around the contents of the BDP Frame >>>>>>>> is to allow a server to know the CC params had not been modified. Of >>>>>>>> course >>>>>>>> you caould ask what sort of information contributes to that hash, to >>>>>>>> make >>>>>>>> the server confident that it can accept CC params from the client and >>>>>>>> believe that these have not been modifed? That could be important? >>>>>>>> >>>>>>>> [NK] The client should not be able to transmit unauthenticated CC >>>>>>>> parameters that are not checked / known by the server. In the current >>>>>>>> spec, >>>>>>>> the client can only send data previously received by the server. >>>>>>>> Malicious >>>>>>>> clients could try to cause a DoS on the server but that would not be >>>>>>>> specific to BDP Frame but to 0-RTT in general. >>>>>>>> >>>>>>>> Should the CC parameters be encrypted? Probably not, as a client >>>>>>>> which is aware of a major decrease in available capacity could compare >>>>>>>> the >>>>>>>> new link capacity to its stored CC parameters and decide not to send >>>>>>>> them. >>>>>>>> If they're encrypted the client can't inspect what CC parameters the >>>>>>>> server >>>>>>>> thinks the link will have. >>>>>>>> >>>>>>>> Perhaps the ID ought to be clearer. The QUIC Session is of course >>>>>>>> encrypted and authenticated, so, in this respect, the BDP Frame is >>>>>>>> protected in transit along the path using TLS. >>>>>>>> >>>>>>>> The current proposal is not to additionally encrypt the CC params >>>>>>>> *within* the BDP, so that a client could read these and utlise as it >>>>>>>> sees >>>>>>>> fit. This still needs to authenticate the entire set of params, so >>>>>>>> that the >>>>>>>> server could trust them. >>>>>>>> >>>>>>>> The params include an endpoint token used by a server to represent >>>>>>>> the remote endpoint - we could have used the client IP source address >>>>>>>> for >>>>>>>> this if the client had an invariant public IP source address. That's >>>>>>>> not >>>>>>>> so common with IPv6 or the use of IPv4 NAPT - so the server has to >>>>>>>> find a >>>>>>>> way to represent it's view of the client as the endpoint token. There >>>>>>>> could >>>>>>>> be possibilities to do this quite differently. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> How should they be authenticated? There are a few options I can see >>>>>>>> here, and I'm unsure which is best: >>>>>>>> >>>>>>>> (1) Authenticated with the TLS certificate >>>>>>>> >>>>>>>> (2) Authenticated with some other asymmetric key >>>>>>>> >>>>>>>> (3) Authenticated using some symmetric key known only to the server >>>>>>>> >>>>>>>> (4) Same as 3 but with a key identifier >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Options 1 and 2 allow the client to verify the authentication over >>>>>>>> the CC parameters, but this doesn't seem to be of much use to me. >>>>>>>> Option 1 >>>>>>>> additionally sets a time limit on use of stored CC parameters, as the >>>>>>>> TLS >>>>>>>> certificate will eventually expire. This doesn't seem to me to be much >>>>>>>> of >>>>>>>> an issue. A new connection far into the future (say 1-2 months) would >>>>>>>> almost certainly have different CC parameters anyway. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Option 3 seems the best to me. It would allow one key to be shared >>>>>>>> across an array of anycast servers, without sharing other keying >>>>>>>> material >>>>>>>> that might be used to protect more sensitive parts of the connection. >>>>>>>> Option 4 additionally expands on this by allowing key rotation without >>>>>>>> immediately invalidating all current stored CC parameters. >>>>>>>> >>>>>>>> So, if this is about how to construct the secure hash, irt seems >>>>>>>> like an interesting topic to find out more, I'd agree. >>>>>>>> >>>>>>>> [NK] We may not specify how to compute the secure hash but that >>>>>>>> could be interesting discussions if you think the draft needs to be >>>>>>>> more >>>>>>>> specific on this. IMHO the client does not need to know how the secure >>>>>>>> hash >>>>>>>> is compute and thus not sure we need interoperability. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> When should the BDP frame be sent? There are two places I can see >>>>>>>> BDP frames being useful to send: >>>>>>>> >>>>>>>> (1) After initial frames but before crypto frames >>>>>>>> >>>>>>>> (2) After crypto frames and before application data >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Option 1 allows for the previously calculated CC parameters to be >>>>>>>> used for the sometimes quite large TLS handshake, but also precludes >>>>>>>> options 1 and 2 for authentication. Option 2 allows for greater >>>>>>>> flexibility >>>>>>>> in authentication, and also makes the BDP frame encrypted in transit. >>>>>>>> I'm >>>>>>>> unsure what the privacy implications of an unencrypted BDP frame are, >>>>>>>> so if >>>>>>>> anyone can come up with a reason CC data shouldn't be observable to an >>>>>>>> intermediary that would be greatly appreciated. >>>>>>>> >>>>>>>> :-) >>>>>>>> >>>>>>>> [NK] Do we need to specify this in the draft or should this be let >>>>>>>> to implementers to define the most relevant approach (w.r.t. frame >>>>>>>> scheduling to format QUIC packets). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Looking forward to hearing your thoughts. >>>>>>>> >>>>>>>> [NK] Thank you for your comments ! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Q Misell >>>>>>>> >>>>>>>> Gorry >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> Any statements contained in this email are personal to the author >>>>>>>> and are not necessarily the statements of the company unless >>>>>>>> specifically >>>>>>>> stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan >>>>>>>> Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a >>>>>>>> company >>>>>>>> registered in Wales under № 12417574 >>>>>>>> <https://find-and-update.company-information.service.gov.uk/company/12417574>, >>>>>>>> LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 >>>>>>>> <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: >>>>>>>> GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South >>>>>>>> Korean >>>>>>>> VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at >>>>>>>> Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, >>>>>>>> trading as >>>>>>>> Glauca Digital, is a company registered in Estonia under № 16755226. >>>>>>>> Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are >>>>>>>> registered trademarks in the UK, under № UK00003718474 and № >>>>>>>> UK00003718468, >>>>>>>> respectively. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ____________________________________________________________________________________________________________ >>>>>>>> >>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>>> confidentielles ou privilegiees et ne doivent donc >>>>>>>> >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>>>>> recu ce message par erreur, veuillez le signaler >>>>>>>> >>>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>>>>>> messages electroniques etant susceptibles d'alteration, >>>>>>>> >>>>>>>> Orange decline toute responsabilite si ce message a ete altere, >>>>>>>> deforme ou falsifie. Merci. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; >>>>>>>> >>>>>>>> they should not be distributed, used or copied without authorisation. >>>>>>>> >>>>>>>> If you have received this email in error, please notify the sender and >>>>>>>> delete this message and its attachments. >>>>>>>> >>>>>>>> As emails may be altered, Orange is not liable for messages that have >>>>>>>> been modified, changed or falsified. >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ____________________________________________________________________________________________________________ >>>>>>>> Ce message et ses pieces jointes peuvent contenir des informations >>>>>>>> confidentielles ou privilegiees et ne doivent donc >>>>>>>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >>>>>>>> recu ce message par erreur, veuillez le signaler >>>>>>>> a l'expediteur et le detruire ainsi que les pieces jointes. Les >>>>>>>> messages electroniques etant susceptibles d'alteration, >>>>>>>> Orange decline toute responsabilite si ce message a ete altere, >>>>>>>> deforme ou falsifie. Merci. >>>>>>>> >>>>>>>> This message and its attachments may contain confidential or >>>>>>>> privileged information that may be protected by law; >>>>>>>> they should not be distributed, used or copied without authorisation. >>>>>>>> If you have received this email in error, please notify the sender and >>>>>>>> delete this message and its attachments. >>>>>>>> As emails may be altered, Orange is not liable for messages that have >>>>>>>> been modified, changed or falsified. >>>>>>>> Thank you. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kazuho Oku >>>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> Kazuho Oku >>>> >>>> >>>> >>> >>> -- >>> Kazuho Oku >>> >>> >>> >> >> -- >> Kazuho Oku >> >
