>Compression has been removed completely from TLS v1.3, the outcome of >the room consensus at IETF-89.
Bummer. Well, in that case, here's a straw man proposal. The extension name is COMPRESS, the EHLO keyword is COMPRESS and is followed by a space-separated list of compression schemes, currently consisting only of DEFLATE (RFC 1951.) There's one new command, COMPRESS which takes as an argument the type of compression to be used. If you want to do both STARTTLS and COMPRESS, the results of doing COMPRESS before STARTTLS are aggessively undefined. The responses to COMPRESS are: 500 compress not supported 501 compression scheme unknown 220 go ahead After a 220 response, subsequent traffic is compressed. It's up to each end to ensure that there's a compression block boundary every time the transmission direction changes, i.e., after each command or response, or if pipelining after each pipelined group. If the compress command fails, the client can at its option continue an uncompressed session or give up. Example S: 220 mx.example smail2 ESMTP C: EHLO client.example S: 250-mx.example S: 250-STARTTLS S: 250-8BITMIME S: 250 COMPRESS DEFLATE C: STARTTLS S: 220 go ahead <TLS negotiation> C: EHLO client.example S: 250-mx.example S: 250-8BITMIME S: 250 COMPRESS DEFLATE C: COMPRESS DEFLATE S: 220 go ahead <subsequent traffic is compressed> ... blah blah ... C: QUIT S: 221 sayonara R's, John _______________________________________________ Shutup mailing list [email protected] https://www.ietf.org/mailman/listinfo/shutup
