Two short comments:
- Would be good to mention that the document does not specify any preset
dictionaries.
- Would be good to mention the reason to have the uncompressed length.
Reading the document I had the same thought that EKR earlier expressed on the
list: that it was some sor
Following the discussion this week I realized some other major issues we'll
need to make sure we cover:
1) Handling proxies here is going to be tricky. The CONNECT generally
needs to specify the hostname which needs to go to the server which has the
ESNI key for what gets sent in the TLS handshak
In addition to this, the document would seem to allow a server to set bit k if
the client did not set that bit. (Or more generally, the responder can set bits
the initiator did not set. )
In fitting with the TLS model, I would recommend allowing a responder to set
only bits that the initiator s
And one more
"The 0xTBD flag can only be send in a ClientHello or CertificateRequest
message. Endpoints that receive a value of 1 in any other handshake message
MUST generate a fatal illegal_parameter alert."
This goes against draft-nir-tls-tlsflags
"A server that supports this extension
Hi,
The document only talks about use in ClientHello, ServerHello, and
EncryptedExtensions. I think it should also discuss usage in
CertificateRequest, Certificate from the server, and Certificate from the
client. It should likely be left to the document that specifies a specific
feature to de
On Thu, Mar 28, 2019, at 16:58, Scott Fluhrer (sfluhrer) wrote:
> * 3.3.1. (Shares-concat) Concatenate key shares
> My concern with this is that there may be algorithms with variable key
> share size (I don’t know of any right now, but ‘extensibility’); if we
> do this, we would want internal le
On Fri, Mar 29, 2019, at 11:18, Andrei Popov wrote:
> > No resumption in TLS 1.3...
> You probably mean no renegotiation in TLS 1.3.
Of course, thank you. Not nearly enough sleep this week.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman
Some more comments after reading the draft in detail.
- The abstract and introduction only talks about the ClientHello use case.
Should shortly mention the CertificateRequest use case as well.
- I notice that the draft does not have any requirement on how the client gets
access to the intermedi
> No resumption in TLS 1.3...
You probably mean no renegotiation in TLS 1.3.
-Original Message-
From: TLS On Behalf Of Martin Thomson
Sent: Friday, March 29, 2019 10:25 AM
To: Hubert Kario ; tls@ietf.org
Subject: Re: [TLS] A use of flags
On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote
Hi,
I am strongly supporting of solving the problem this draft is trying to solve.
This is a problem that the EMU WG has identified and discussed in the past.
https://tools.ietf.org/html/draft-ms-emu-eaptlscert-02
I will add text discussing draft-thomson-tls-sic-00 to
draft-ms-emu-eaptlscert-0
On Thu, Mar 28, 2019, at 14:46, Hubert Kario wrote:
> what about resumption and renegotiation?
No certificates in resumption.
No resumption in TLS 1.3 (and I don't care about TLS 1.2 any more).
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mai
On Thu, Mar 28, 2019, at 14:54, Hubert Kario wrote:
> what about making sure that the legacy and flags remain in-sync? we will have
> to send the legacy encoding for many years to come, so only thing it would
> possibly reduce the size of is ServerHello or EncryptedExtensions
Those are messages
12 matches
Mail list logo
