I'm hesitant to call a 16-bit registry "big" in any context. But if allocating a value requires a specification, that's probably okay. (There aren't even close to 2^16 RFCs in total)
On Wed, Mar 21, 2018 at 3:54 AM, Eric Rescorla <[email protected]> wrote: > > > On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik <[email protected]> > wrote: > >> Hi Sean: >> >> Quick question: does "closing the registry" not contradict catering >> towards crypto agility? What happens if, say, one wishes to add another >> signature scheme, besides Ed25519, to the mix. If there is no private >> field, does this mean that, e.g., Schnorr+BSI Brainpool256r1 is now ruled >> out? >> > > No. Private just means "we're not going to allocate these code points, so > you should use them without coordination". > > The key point here is that this is a big space and so we're instead going > to make it easy for people to reserve code points by writing a stable spec, > that need not be an IETF standard, and that's what they should do. > > > -Ekr > > >> >> My more serious concern is, however, that if the Private Use case is >> "verboten", there is no chance for people to signal private extensions >> (since IETF will just have killed this off). >> >> I do not think it is prudent to have a slow process in place (IETF >> standardization) to effectuate crypto agility, if private use can already >> do this without waiting for 3-year public discussions and heated debate (if >> a weakness is discovered, dark forces will exploit this right away and >> won't wait for IETF to catch up to exploit an issue). >> >> As case in point, suppose US Gov't wants to roll its own "Suite A" >> scheme, or if one wants to use TLS with something tailored towards the >> sensor world (which operates in quite a hostile environment for >> implementation security), how is one going to do this in context of TLS if >> the signaling required has just been removed? >> >> NOTE: this is not an invite for endless discussions on the legitimacy of >> whoever may wish a private extensions (it is private after all), it does >> question though the wisdom of removing the option for using this. If Zulu >> hour arrives, one should have tools to act... >> >> Best regards, Rene >> >> On 3/16/2018 10:01 AM, Sean Turner wrote: >> > During Adam Roach’s AD review of draft-ietf-tls-tls13, he noted >> something about the HashAlgorithm and that made me go look at what was said >> in draft-ietf-tls-iana-registry-updates. Turns out that 4492bis >> assigned some values draft-ietf-tls-iana-registry-updates was marking as >> reserved. I have fixed that up in: >> > https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/65 >> > >> > One further point brought out in discussions with Adam was that if >> we’re really closing the HashAlgorithm and SignatureAlgorithms registry we >> need to also mark 224-255 as deprecated. Currently these are marked as >> Reserved for Private Use. So the question is should we mark 224-255 as >> deprecated in these two registries? >> > >> > spt >> > _______________________________________________ >> > TLS mailing list >> > [email protected] >> > https://www.ietf.org/mailman/listinfo/tls >> >> >> -- >> email: [email protected] | Skype: rstruik >> cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 >> >> _______________________________________________ >> TLS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
