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

[Lucas Pardue <[e-mail]>]

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?

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.
>
>
> 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?
>
> 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.
>
>
> 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.
>
> :-)
>
>
> Looking forward to hearing your thoughts.
> 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.
>
>
>