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?
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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- email: rstruik....@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
