Paul Wouters writes: > On Thu, 2 Nov 2017, Valery Smyslov wrote: > > > RFC7427 allows peers to indicate hash algorithms they support, thus > > eliminating ambiguity in selecting a hash function for digital signature > > authentication. However, recent advances in cryptography lead to a > > situation > > when some signature algorithms have several signature formats. > > I think it is worth investigating a bit more. > > > A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, > > This example is indeed the first known problem. One of the most > widespread implementations of 7427 does not support PSS. I'm not > sure 8247 making RSASSA-PSS will help much.
One question that comes to my mind is that why is the server offering CA which issues RSASSA-PSS certificates it is does not support those certificates. I.e. server is saying it will use CA which it cannot use, and I would say that is configuration error in the server side. Also usually client will know which certificate it must use when connecting to the server, exactly as it must know which PSK it must use when it connects to which server. I can see that there are corner cases where the adminstrative domain is updating from PKCS#1 certificates to the RSASSA-PSS, and not all of its infrastructure is updated yet, but it can prevent issues by either making sure server sides are updated before clients, or using separate CA for different key types. Another case where this might happen when client is doing opportunistic encryption i.e., it does not even try to authenticate, thus it does not care which key it is using or what key the other end is using, thus it will just pick one of its own keys and use that. In most cases IPsec is considered as "requires preconfiguration" use case, i.e., I cannot random try to connect host A with IPsec and assume that will work. It is same thing with secure shell, i.e., unless I have account and password or key configured for host A, there is no point of trying to see if I can log in to the host A. I.e., if you need to configure that this is the CA I want to trust when connecting to host A, and this is the identity I am going to use for myself, it is not that much more to configure that this is the key I am going to use when authenticating to host A. With PSK I will need to explictly give the keys anyways, why should the certificates be that much different case, that you cannot preconfigure the key you are using. TLS and HIP are examples of cases which are more or less "no preconfiguration required", i.e., you can just try to connect and if it works then you can use connection. This is the reason why the RFC7427 only negotiates the hash algorithm, and the section 5 of the RFC 7427 gives several ways of solving this issue without doing protocol changes. I still think this is more or less a configuration mismatch issue, i.e., if your configuration is wrong you will end up in trouble, but if you plan your upgrade process, or configure your systems correctly, this issue is disappears. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
