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.
