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

[Gorry Fairhurst <[e-mail]>]

On 05/11/2023 15:41, Marten Seemann wrote:
> > 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.
I think there may be a confusion here. I'd prefer to CC as a function 
that works unidirectional the sender implementing the CC, the receiver 
providing ACKs. In this case, the client's CC doesn't typically matter - 
the params are not that sensitive to common CC's since this is about the 
initial slow-start/getting-up-to-speed.
> 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.

I think we could be talking across one another about the use of the CC 
params - the BDP_FRAME proposal is about deciding whether a receiver 
desires to use the Careful Resume method on the path for a specific 
connection towards that receiver. There are times when a recipient opens 
multiple connections, understands local link/network conditions or 
simply knows that a specific connection will not be a high-rate 
transfer. Understanding this allows it to help a server decider when to 
use Careful Resume.

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