Authentication in draft-kuhn-quic-bdpframe-extension

[Q Misell <[e-mail]>]

Hi all,

I've been working with Gory (and others) on actually implementing the BDP
frame extension, and further refining the draft based on experience from
implementation.

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

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.

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

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.