Re: [TLS] A flags extension

[Hubert Kario <[e-mail]>]

On Tuesday, 2 April 2019 18:29:18 CEST Christian Huitema wrote:
> On 4/2/2019 4:42 AM, Hubert Kario wrote:
> > On Monday, 1 April 2019 23:05:41 CEST Martin Thomson wrote:
> >> On Mon, Apr 1, 2019, at 12:40, Hubert Kario wrote:
> >>>>> would possibly reduce the size of is ServerHello or
> >>>>> EncryptedExtensions
> >>>> 
> >>>> Those are messages where we have size pressure.
> >>> 
> >>> why? in what use case?
> >> 
> >> QUIC. We have 3600 bytes to play with in that flight. And Certificate is
> >> often more than that.
> > 
> > then maybe it's QUIC that should be modified to allow for more than 3600
> > bytes to actually make it deployable?
> > 
> > I mean, seriously, if you you need to be bit-pinching now, what will
> > happen
> > when PQC gets deployed?!
> 
> The problem is "amplification" -- how much data the server is willing to
> send without assurance that the client's address is not spoofed. The
> current decision is "no more than 3 times the size of the data sent by
> the client", which is enforced to be at least 1200 bytes. Quic does work
> if the server flight is longer than that, but then the handshake takes
> at least 2*RTT instead of 1*RTT.

so how many connections will end up with a 2RTT instead of 1RTT handshake if 
the server response is not smaller by those 12 bytes or so?

how many connections will actually end up with larger server response because 
they need to send just one flag?
 
> That said, yes, there is a problem if PQC requires the client hello to
> be larger than 1200 bytes.

or the server has certificates with PQC signatures that are few KiB long...

the more PQC is deployed, to more the balance will be skewed towards the 
server, as far as data sent is concerned
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic