[IPsec] Interoperability problem concerning RFC 7427

[Tero Kivinen <[e-mail]>]

[This is bit old email, but I have not seen any replies to this, and I
am sending this as implementor not as chair.]

Valery Smyslov writes:
> The problem is that RFC7427 doesn't provide any means to find out
> what kind of signatures peer supports. If you have RSA certificate,
> you need somehow to guess whether you can use newer PSS signature
> format or should stick to old PKCS 1 one. The SIGNATURE_HASH_ALGORITHMS
> notification doesn't provide any information of this kind. RFC7427
> is silent whether support for RSASSA-PSS is required to be compliant
> with it, so I think it is absolutely legal now to have support for Digital Signature
> authentication method and have no support for RSASSA-PSS 
> (as in the product we have tested with).
> The draft draft-ietf-ipsecme-rfc4307bis does requires that if
> Digital Signatures are supported, then RSASSA-PSS with SHA2-256
> MUST be supported. However, even if it becomes RFC in near future,
> it'll take a couple of years before it is adopted by major vendors.

Section 5 of the RFC7427 covers this, and we also discussed this when
the RFC was being written. The consensus was that in most cases there
is existing configuration between peers anyways, thus configuring
which key to be used is just one more configuration option to do, and
that is easy way to solve the issue.

I.e., in the end we decided we do not want to add negotiation for the
public key algorithm.

[1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08701.html
[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html

> I think that it is a more fundamental problem: RFC7427 allows peers
> to announce what hash functions they support, but the peers 
> cannot announce what kinds of signatures (or what signature formats)
> they support. Few years ago life was simpler: there were a couple
> of widely used signature schemes and they use different types of
> public keys. So, if you had RSA certificate, you could be sure that
> RSA PKCS 1 signature format would be understood by anyone.
> Now we have new incompatible RSA signature format - RSASSA-PSS
> and mere having RSA certificate is not enough to choose right
> signature format. I envision that similar situation can repeat
> in the future with Elliptic Curve certificates. Now new kind of signature
> is being developed for Edwards curve public keys - EDDSA.
> However, as far as I anderstand, any Edwards curve key can
> be converted to short Weierstrass's form and used in ECDSA.
> So we'll probably have a mess when some implementations
> support EDDSA, while some use Edwards keys in ECDSA
> (at least for a while), that will result in interoperability problems.

I think the current consensus is that you should not use same private
key with different signature algorithms. I.e., I think they are saying
that you should not use same private key for the different versions of
the EdDSA etc.

On the other hand draft-irtf-cfrg-eddsa do say that "one can use the
same keypair for both Ed25519, Ed25519ctx and Ed25519ph" because the
signature method is defined so it is still safe.

Anyways, I would expect that nobody would want to use the same key for
both EdDSA and ECDSA. And whether you want to use same private key for
both Ed25519 and Ed25519ph is something that some people say you
should not.

So I do not think this issue will come up with using same private key
for different EC signing methods, but it will come up with RSASSA-PSS.

> So, my question is - what to do with all this.
> 1. Do nothing. Coming back to the interoperability problem we have,

This is what we decided when we published RFC7427. 

>     it is possible to find some workarounds:
>     - don't use RSASSA-PSS until it becomes ubiquitous (however if everybody
>         follows this way it'll never become ubiquitous)
>     - it is possible for the initiator to restart exchange if it receives
>        AUTHENTICATION_FAILED while using RSASSA_PSS
>         and use RSA PKCS 1 in the new run. However, this approach
>         will slow down connection setup and waste resources of
>         both initiator and responder.
>     - it is possible for responder to look at the format of signature 
>         the initiator used and act in accordance - if the initiator
>         doesn't use RSASSA-PSS then don't use it.
>     These are all workarounds and they complicate implementations
>     and waste resources for no good reason.

We said that in initiator you need to either try all keys, use
Certificate request as hint, or have preconfiguration.

In the responder you can use the same format than the initiator used
(if it used signature authentication). If not, you can either use
certificate requests as hint, or use preconfiguration.

> 2. Add some indication of signature form/format the peers support.
>     I can see two possible solutions.
>     - define new entries in Hash Algorithms registry
>         that are not hash functions but are rather signature formats.
>         For example, add RSASSA_PSS. If it is included
>         in SIGNATURE_HASH_ALGORITHMS notification.
>         it will mean that this format is supported with any real hash
>         algorithms that are included in this notification.
>         It is clearly a hack of RFC 7427.
>     - define new notification SIGNATURE_FORMATS, which
>         will include supported signature forms/formats.
>         It seems to be a most "proper" way, however 
>         it is the slowest one (new RFC is needed).

As we already once decided we are not going to do it, I do not think
we want to come back to this. It is fine to come back to same issues
if something has changed, but I do not think there has been any real
changes in here, actually I think the issue is getting easier, as
rfc4307bis will say that RSASSA-PSS is MUST, thus this issue will go
away and everybody can start using RSASSA-PSS, and just have some
fallback option for old implementations not supporting rfc4307bis.

I do not think this is issue for ECDSA or EdDSA. And
draft-nir-ipsecme-eddsa-01 says that *ph SHOULD ONT be used... 
-- 
[e-mail]