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

[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.

>
> 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