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

[Gorry Fairhurst <[e-mail]>]

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]> *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.