Orange Restricted
*De :* Gorry Fairhurst <[email protected]>
*Envoyé :* samedi 4 novembre 2023 14:45
*À :* STEPHAN Emile INNOV/NET <[email protected]>; Nicolas Kuhn
<[email protected]>; [email protected]
*Objet :* Re: Authentication in draft-kuhn-quic-bdpframe-extension
On 04/11/2023 13:28, [email protected] 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 <[email protected]> <[email protected]> *De la
part de* Nicolas Kuhn
*Envoyé :* samedi 4 novembre 2023 12:43
*À :* [email protected]
*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 <[email protected]>
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.
