Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS

[Nick Harper <[e-mail]>]

On Fri, Sep 27, 2019 at 10:12 AM Roberto Peon <[e-mail]> wrote:
>
> My preference would be to have a facility that would allow an application to ensure that some limited/constant-size data is in every packet that it sends until it gets an ACK.
>
>
> This would allow control messages to be sent reliably, but avoid the HoL blocking issues.
> The real issue that, I believe, we’re trying to solve here is to ensure that the first packet has everything in it that is needed for interpretation/settings, etc.
>
That sounds like a good way to phrase the problem. I'd clarify it by
saying the problem we're trying to solve is to ensure that when we
send the first application data packet (i.e. 0- or 1-RTT encrypted) we
have everything negotiated that we need.

> I also believe that this could be of use in a number of other HoL-prevention things.
>
> It is my opinion that this is a QUICv2 feature, if it becomes something we’d want at all.
>
> -=R
>
>
>
> From: QUIC <[e-mail]> on behalf of Mikkel Fahnøe Jørgensen <[e-mail]>
> Date: Thursday, September 26, 2019 at 10:55 PM
> To: Christian Huitema <[e-mail]>, Nick Harper <nharper=[e-mail]>
> Cc: IETF QUIC WG <[e-mail]>
> Subject: Re: Add application parameters to QUIC handshake and use it for H3 SETTINGS
>
> It seems to be possible to facilitate a man-in-the-middle attack on application parameters unless the application takes counter-measures which would complicate matters and likely introduce delays anyway.
>
A man in the middle wouldn't be able to tamper with application
parameters without causing the handshake to fail - this is the same as
transport parameters. (If they are tampered with, the two endpoints
will have different TLS handshake transcripts, thus derive different
keys and Finished messages.)

> I also wonder how this would work with 0-RTT since it cannot be assumed that application parameters would be remembered across connenctions.
>
Each application would still need to define how it handles 0-RTT
(likely to remember the server's previous application parameters, like
we currently do for transport parameters and H3 settings), with the
default assumption being that an application does not support 0-RTT.