Hi all,
the currently defined “pre_shared_key” extension allows clients to send
a list of the identities. I was wondering in what use cases this is
useful and what policy guides the server to pick the most appropriate
psk identity. I couldn't find any discussion in the document about this
aspect.
Hi Ekr, Hi all,
reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I
noticed the TLS ExtensionType Registry on page 77 & page 78.
The "TLS 1.3" column has one of four values, namely
- "Client", indicating that the server shall not send them.
- "Clear", indicating that they
On Thu, Aug 11, 2016 at 08:56:25PM +0200, Hannes Tschofenig wrote:
> Hi Ekr, Hi all,
>
> reading through https://tools.ietf.org/html/draft-ietf-tls-tls13-14 I
> noticed the TLS ExtensionType Registry on page 77 & page 78.
>
> The "TLS 1.3" column has one of four values, namely
>
>- "Client",
Looking at those emails, I am prompted to wonder if anyone can justify
the existence of a ciphersuite with a double-sized key and half-sized
authentication tag. RFC 6655 doesn't really explain how that is a
useful thing.
On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos wrote:
> On Tue, 2016-0
On 12 August 2016 at 05:09, Ilari Liusvaara wrote:
> Actually, the server_name could be made into 'client', since the only
> thing server sends about server_name is an ACK, meaning it has taken it
> into "consideration" (in some vague way).
I disagree. If it can be encrypted, then it should be.
