Re: [TLS] (crypto agility may benefit from private extensions) Re: Additional changes for draft-ietf-tls-iana-registry-updates

[Rene Struik <[e-mail]>]

Hi Eric:

I may have an incorrect impression about the code points, but, let us
say, one finds out an attack on one of the TLS1.3 algorithms and wishes
to swap the algorithm set for a new one (that is clearly specified, say,
"RS-Alg-X"). How does one do this if one marks 224-255 as deprecated.
How does one signal private use of "RS-Alg-X" now. If you could tell me,
please let me know, so that I feel more at ease with this. {This should
not be something where reliability is impossible to achieve).

Thanks!

Rene

> 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?

On 3/20/2018 10:54 AM, Eric Rescorla wrote:
>
>
> On Tue, Mar 20, 2018 at 2:51 PM, Rene Struik <[e-mail]
> <mailto:[e-mail]>> 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
>     <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
>     > [e-mail] <mailto:[e-mail]>
>     > https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>
>     --
>     email: [e-mail] <mailto:[e-mail]> |
>     Skype: rstruik
>     cell: [phone] <tel:%2B1%20%28647%29%20867-5658> | US: +1
>     [phone] <tel:%2B1%20%28415%29%20690-7363>
>
>     _______________________________________________
>     TLS mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/tls
>     <https://www.ietf.org/mailman/listinfo/tls>
>
>

-- 
email: [e-mail] | Skype: rstruik
cell: [phone] | US: [phone]