On Wednesday, 27 February 2019 13:52:57 CET Stephen Farrell wrote:
> On 27/02/2019 12:30, Hubert Kario wrote:
> > I'm not sure which part for the key_share extension you mean as being
> > empty, but the key_exchange in the KeyShareEntry can't be empty, per RFC
> > 8446,>
> > Section 4.2.8:
> > struct {
> >
> > NamedGroup group;
> > opaque key_exchange<1..2^16-1>;
> >
> > } KeyShareEntry;
>
> Ah sorry, you're right - there is one byte in the
> key_exchange with a value 0x00 in a greasy KeyShareEntry
> I just looked at.
>
> And a different browser doing tls1.2 sent 2 greasy
> extensions, one with no data and another with a single
> byte (0x00 again).that's ok, the extensions in general can have empty payloads > I guess my question remains though, as to whether more > bytes ought be sent in these fields sometimes and whether > or not they also ought be random values. > > FWIW, I guess it'd make sense to send a range of random > length random values some of the time, but mostly I'm > wondering what other folks are doing/expecting. for extensions doing an empty one and one with just few bytes should be sufficient For key_share, to simulate actual use I'd say the values should be at least few dozen bytes long. That does inflate unnecessarily the ClientHello, so it's a balancing act... -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
