[IPsec] Interoperability problem concerning RFC 7427

"Valery Smyslov" <svanru@gmail.com> Thu, 15 September 2016 15:27 UTC

Message-ID: <4413733F9BF24D94821C1814E88C3C26@buildpc>
From: Valery Smyslov <svanru@gmail.com>
To: IPsecME WG <ipsec@ietf.org>
References: <MWHPR09MB14403946B9D23FF98C744FBEF0E40@MWHPR09MB1440.namprd09.prod.outlook.com>
Date: Thu, 15 Sep 2016 17:28:53 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipsec/0XYpWpMrtU_IXmn_RxfWWvsXztM>
Subject: [IPsec] Interoperability problem concerning RFC 7427
Precedence: list

Hi,

we recently ran into one interoperability problem that is concerned
with RFC 7427.

We start testing RSASSA-PSS with another vendor product and found, 
that while it supports Digital Signature authentication method, it seems
to not support RSASSA-PSS signatures in IKE. As a result, the SA 
is failed to be created if we use RSASSA-PSS (and we do use it
because we want to be compliant with RFC-to-be draft-ietf-ipsecme-rfc4307bis,
that states that with Digital Signature RSASSA-PSS-SHA256 is MUST).

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.

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.

So, my question is - what to do with all this.
1. Do nothing. Coming back to the interoperability problem we have,
    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.
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).

What the WG thinks of all this?

Regards,
Valery.

[IPsec] IPsecME Status update 2016-09-02 Waltermire, David A. (Fed)
[IPsec] Interoperability problem concerning RFC 7… Valery Smyslov
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov
[IPsec] Interoperability problem concerning RFC 7… Tero Kivinen
Re: [IPsec] Interoperability problem concerning R… Yoav Nir
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov
Re: [IPsec] Interoperability problem concerning R… Paul Wouters
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov
Re: [IPsec] Interoperability problem concerning R… Yoav Nir
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov
Re: [IPsec] Interoperability problem concerning R… Tero Kivinen
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov
Re: [IPsec] Interoperability problem concerning R… Tero Kivinen
Re: [IPsec] Interoperability problem concerning R… Valery Smyslov