[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] I-D Action: draft-ietf-tls-certificate-compression-02.txt
From: Benjamin Kaduk <bkaduk () akamai ! com>
Date: 2018-01-31 21:41:34
Message-ID: 9126f0e6-e135-5421-f9b9-1ff880fd19e8 () akamai ! com
[Download RAW message or body]
On 01/30/2018 04:02 PM, Victor Vasiliev wrote:
> On Mon, Jan 29, 2018 at 10:22 AM, Benjamin Kaduk <bkaduk@akamai.com
> <mailto:bkaduk@akamai.com>> 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.
[Attachment #3 (text/html)]
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 01/30/2018 04:02 PM, Victor Vasiliev wrote:<br>
<blockquote type="cite"
cite="mid:CAAZdMaczieoBKBo21Hpm36V6k=SY_UORqwguma0QGh3JJW4wPA@mail.gmail.com">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mon, Jan 29, 2018 at 10:22 AM,
Benjamin Kaduk <span dir="ltr"><<a
href="mailto:bkaduk@akamai.com" target="_blank"
moz-do-not-send="true">bkaduk@akamai.com</a>></span>
wrote:
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
The new note about "no ServerHello extension to echo back"
makes me<br>
wonder if (not) echoing back in Certificate should also be
mentioned,<br>
since the TLS 1.3 paradigm is that CertificateRequest
extensions are<br>
also "requests" that can get "responses" in the
Certificate message.<br>
</blockquote>
<div><br>
</div>
<div>True, though I guess this depends on your definition of
"response"?</div>
<div> </div>
</div>
</div>
</div>
</blockquote>
<br>
I'm thinking of the text in section 4.2:<br>
<br>
<pre class="newpage"> 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.</pre>
<br>
-Ben<br>
<br>
<blockquote type="cite"
cite="mid:CAAZdMaczieoBKBo21Hpm36V6k=SY_UORqwguma0QGh3JJW4wPA@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
I also wondered whether there was any sense in reserving
codepoint 0 (of<br>
CertificateCompressionAlgorith<wbr>m) for "uncompressed".
I guess not, since<br>
support for uncompressed certificates is implicit by means
of not using<br>
the extension. But sometimes keeping value 0 (basically)
reserved is<br>
still useful.<br>
</blockquote>
<div><br>
</div>
<div>I've considered that, but decided that this would just
introduce two ways to do</div>
<div>the same thing (send certificate uncompressed), so I
decided against it.</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic