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

[Gorry Fairhurst <[e-mail]>]

On 15/11/2023 15:40, Q Misell 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.
i think that is where I reached also after various suggestions at IETF 
Prague, and one of the opportunities is to allow the recipent to decide 
when to use the CR method.
>
> 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.
Yes the CR ID notes we ought to set an expiry time for the CC Params, 
and we ought to try to firm up with a proposal for how lomg to keep th 
CC info.
>
> > 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 can vlarify that: This is likely a left-over from one of the previous 
designs using a TLS ticket, which we have moved-on from. The BDP Frame 
is intended for 1-RTT, sorry.
> 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.
I will read this.
>
> 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.
>
>
Thanks,

Gorry

>
> 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]>
>>>>                                 <mailto:[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
>