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
