On Sun, 2016-11-27 at 15:13 +, Alessandro Ghedini wrote:
> On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> > I am currently trying to figure out how much of QUIC certificate
> > compression can be adapted to work with TLS. I will submit a draft
> > as soon
> > as I have a wo
Only the client ever sends the "psk_key_exchange_modes” extension. In fact,
the server MUST NOT send a "psk_key_exchange_modes" extension.
The "pre_shared_key” extension is already divided into the structures used by
the client and the server. Why not add the ke_modes to the client part of the
On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley wrote:
> Only the client ever sends the "psk_key_exchange_modes” extension. In
> fact, the server MUST NOT send a "psk_key_exchange_modes" extension.
>
> The "pre_shared_key” extension is already divided into the structures used
> by the client and
Eric:
> On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley wrote:
> Only the client ever sends the "psk_key_exchange_modes” extension. In fact,
> the server MUST NOT send a "psk_key_exchange_modes" extension.
>
> The "pre_shared_key” extension is already divided into the structures used by
> the
https://github.com/tlswg/tls13-spec/pull/763
Barring technical objections (e.g., this is incorrect), I intend to merge
this PR requiring point validation on Wednesday.
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
At this point, my personal opinion is to move on from TLS 1.3 to either TLS
4/4.0 or TLS 2017.
After 15 years, everyone but us still calls it SSL. We need to admit that we
lost the marketing battle and plan for a world where everyone calls “TLS X”
“SSL X”. Even “new” implementations call themse
