Re: Authentication in draft-kuhn-quic-bdpframe-extension

[Q Misell <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> wrote:
>
>>
>>
>> 2023年11月6日(月) 13:38 Gorry Fairhurst <[e-mail]>:
>>
>>> See below:
>>>
>>> On 06/11/2023 10:59, Kazuho Oku wrote:
>>>
>>>
>>>
>>> 2023年11月6日(月) 10:08 Gorry Fairhurst <[e-mail]>:
>>>
>>>> On 05/11/2023 15:49, Kazuho Oku wrote:
>>>>
>>>>
>>>>
>>>> 2023年11月5日(日) 16:41 Marten Seemann <[e-mail]>:
>>>>
>>>>> > 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 <[e-mail]>
>>>>> 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 <[e-mail]> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2023年11月4日(土) 15:44 <[e-mail]>:
>>>>>>>
>>>>>>>> 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 <[e-mail]>
>>>>>>>> *Envoyé :* samedi 4 novembre 2023 14:45
>>>>>>>> *À :* STEPHAN Emile INNOV/NET <[e-mail]>; Nicolas
>>>>>>>> Kuhn <[e-mail]>; [e-mail]
>>>>>>>> *Objet :* Re: Authentication in draft-kuhn-quic-bdpframe-extension
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 04/11/2023 13:28, [e-mail] 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 <[e-mail]> <[e-mail]> *De la
>>>>>>>> part de* Nicolas Kuhn
>>>>>>>> *Envoyé :* samedi 4 novembre 2023 12:43
>>>>>>>> *À :* [e-mail]
>>>>>>>> *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 <
>>>>>>>> [e-mail]> 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
>>
>