I am happy to announce that TLS 1.3 is already mandatory to support for all
uses of TLS in 3GPP 5G (and also LTE, 3G systems that are updated to the latest
release). Release 15 makes TLS 1.3 mandatory for networks and Release 16 makes
TLS 1.3 mandatory also for MEs (i.e. mobile phones) while
Martin,
Thanks for the corrections, and thank you others who have reviewed the
patches. I've updated the PRs appropriately.
Nick
On Wed, May 30, 2018 at 6:48 PM Martin Thomson
wrote:
> I've reviewed changes. Thanks for writing them up Nick.
>
> Two concerns:
>
> On #26, I think that there is
On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann
wrote:
> Eric Rescorla writes:
>
> >As noted earlier, it's premature for TLS-LTS to request a code point
> because
> >the enabling document has not yet been published,
>
> And yet -compression was allocated a codepoint without this.
Compression
Eric Rescorla writes:
>As noted earlier, it's premature for TLS-LTS to request a code point because
>the enabling document has not yet been published,
And yet -compression was allocated a codepoint without this. This whole mess
was created because I asked for early allocation and was told to
Since there is a conflict with deployments with extension code point 26
IANA has now assigned the compress_certificate extension code point 27 from
the TLS extensionType values registry.
On Wed, May 23, 2018 at 6:23 PM, Sean Turner wrote:
> IANA has assigned the following values:
>
> 1) In the
​David Benjamin writes:
>I probed a bunch of servers yesterday and found evidence of yet another
>collision at 26! It's possible these are TLS-LTS implementations, but a lot
>of them additionally only support RSA decryption ciphers, which makes this
>seem unlikely.
Another reason why it should
David Benjamin writes:
>Our problems with 26 and 40 are because we like to make "official"
>allocations consecutively, and then "unofficial" allocations missed the
>obvious corollary: do not mimic this.
Yeah, based on being asked to wait for the registry draft I assumed nothing
would be issued
Based on this, I propose that IANA allocates a new !26 Early Data code
point for compressed certificates (that's mechanical).
As noted earlier, it's premature for TLS-LTS to request a code point
because the enabling document has not yet been published, so we can defer
the question of its use of
Just picking a random high number for QUIC seems reasonable for this stage.
None of this still will escape outside of draft QUIC versions (which,
themselves, will be short-lived) and a collision at high numbers isn't
likely anyway. Our problems with 26 and 40 are because we like to make
"official"
I think there's also some room to just mark 26 as "Reserved - unauthorized
use has rendered this value unsuitable for official allocation".
-Ben
On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote:
> Based on this, I propose that IANA allocates a new !26 Early Data code
> point for
I probed a bunch of servers yesterday and found evidence of yet another
collision at 26! It's possible these are TLS-LTS implementations, but a lot
of them additionally only support RSA decryption ciphers, which makes this
seem unlikely. These servers do not appear to do anything with the
We might also want to mark 40 similarly given the ExtendedRandom collision
that caused issues with key_share.
On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk wrote:
> I think there's also some room to just mark 26 as "Reserved - unauthorized
> use has rendered this value unsuitable for official
12 matches
Mail list logo
