mly to avoid issues with concurrent applications and I offer
> > >>> 0xbb31 as a high-quality, random number. Since we had a triple
> > >>> collision in this case, random-assignment's virtues are currently
> > >>> particularly clear.)
> > >>
This scheme probably isn't sufficient by itself, since a middlebox just has
to be aware of the anti-ossification extension and can parse the server's
response by decrypting it with the known mapping (either from the RFC or
fetching the latest updated mapping), and then ossifying on the contents of
e purpose of _0 suffix in the following:
>
> client_application_traffic_secret_0
> server_application_traffic_secret_0
>
> with regards,
> Saravanan
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/lis
Maintaining my hum from the meeting, I prefer keeping TLS 1.3 over
renaming, primarily because there's now a good amount of
documentation/implementation in the wild that refers to TLS 1.3, and we'll
need to keep around the new equivalence of TLS 2 (or 4)=TLS 1.3.
On Sat, Nov 19, 2016, 8:31 AM Ira
Being able to send supported_groups does allow a server to choose to make a
tradeoff between an extra round trip on the current connection and its own
group preferences. One example where a server might want to do this is
where it believes that X25519 is likely a more future-proof group and would
p
gt;>> the list and indicate why. This call will close on 8 August 2024.
>>>
>>> Thanks,
>>> Sean
>>> ___
>>> TLS mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@i
