Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt

[Benjamin Kaduk <[e-mail]>]

On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
> On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     The new note about "no ServerHello extension to echo back" makes me
>     wonder if (not) echoing back in Certificate should also be mentioned,
>     since the TLS 1.3 paradigm is that CertificateRequest extensions are
>     also "requests" that can get "responses" in the Certificate message.
>
>
> True, though I guess this depends on your definition of "response"?
>  

I'm thinking of the text in section 4.2:

   Extensions are generally structured in a request/response fashion,
   though some extensions are just indications with no corresponding
   response.  The client sends its extension requests in the ClientHello
   message and the server sends its extension responses in the
   ServerHello, EncryptedExtensions, HelloRetryRequest and Certificate
   messages.  The server sends extension requests in the
   CertificateRequest message which a client MAY respond to with a
   Certificate message.  The server MAY also send unsolicited extensions
   in the NewSessionTicket, though the client does not respond directly
   to these.

   Implementations MUST NOT send extension responses if the remote
   endpoint did not send the corresponding extension requests, with the
   exception of the "cookie" extension in HelloRetryRequest.  Upon
   receiving such an extension, an endpoint MUST abort the handshake
   with an "unsupported_extension" alert.


-Ben

>     I also wondered whether there was any sense in reserving codepoint
>     0 (of
>     CertificateCompressionAlgorithm) for "uncompressed".  I guess not,
>     since
>     support for uncompressed certificates is implicit by means of not
>     using
>     the extension.  But sometimes keeping value 0 (basically) reserved is
>     still useful.
>
>
> I've considered that, but decided that this would just introduce two
> ways to do
> the same thing (send certificate uncompressed), so I decided against it.

Sure.  I don't see a reason to add a code point for uncompressed, but
maybe there is an aesthetic argument for leaving 0 reserved entirely. 
But I definitely do not insist on anything.