Subject: [IPsec] Interoperability problem concerning RFC 7427

From: Tero Kivinen <[email-masked]>
Date: Tue, 4 Oct 2016 16:45:13 +0300

[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... 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Oct 2016 17:11:18 +0300

Hi Tero, 

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

No this was different issue. I remember that discussion very well (since
I initiated it) and I wouldn't start it over again. 

The issue we came across is not about different algorithms
(say indicating whether we need to use RSA or ECDSA if we have
both certificates). The algorithm is essentially one - RSA, and we have 
exactly one RSA certificate. However, we can create AUTH
payload using RSA-PKCS 1.5 or using RSASSA-PSS signature
formats. And we came across that the peer from different
vendor doesn't understand RSASSA-PSS signatures while
supporting RFC7427. This is the issue. We have no clue
whether it is safe to use RSASSA-PSS or not and
the RFC gives us no means to get this clue. This is the problem. 

[snip]

> for different EC signing methods, but it will come up with RSASSA-PSS.

I'm not so sure that EC signing methods will not suffer from 
this issue, giving the speed the new ones appear and become popular.

> This is what we decided when we published RFC7427. 

No, it was different discussion. You persuaded me then
that Certificate Request etc. works well for selecting
the proper private key. It doesn't work at all for selecting
the "proper" signature format.

> Certificate request as hint, or have preconfiguration.

Certificate Request doesn't work. Preconfiguration doesn't scale.
Trying all signature formats is possible, but I expect that 
many implementers (and users) will just disable
RSASSA-PSS, that is a bad thing...

> certificate requests as hint, or use preconfiguration.

Yes, it is possible for the responder to look at the signature
format the initiator used and act correcpondently.
However, if many initiators disable RSASSA-PSS for the
request then responders won't use it either, leading
to even more slow adoption of this signature sceme.

> if something has changed, but I do not think there has been any real

It is a bit different issue. And it is practical.

> fallback option for old implementations not supporting rfc4307bis.

Yes, the issue with RSASSA-PSS should go away once
the RFC4307bis is issued and adopted by majority of vendors.
It'll take a couple of years. 

> draft-nir-ipsecme-eddsa-01 says that *ph SHOULD ONT be used... 

Not so sure...

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Oct 2016 20:38:08 +0300

> On 4 Oct 2016, at 17:11, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Tero, 
>>> authentication method and have no support for RSASSA-PSS (as in the product we have tested with).
> both certificates). The algorithm is essentially one - RSA, and we have exactly one RSA certificate. However, we can create AUTH

There is one clue.  The signature in the certificate. If the certificate is signed with PKCS #1.5 it is safest to use PKCS #1.5 for authentication. If the certificate is signed with PSS then it’s probably safe to use PSS in the signature.

I know this greatly delays the deployment of PSS, because for a certificate issuer PKCS #1.5 is the safest route, but I don’t know that we can do better without either a negotiation or prior agreement (which just means configuration from an implementer’s POV)

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 4 Oct 2016 21:08:56 +0300

Hi Yoav,

> There is one clue.  The signature in the certificate. If the certificate is signed with PKCS #1.5 it is safest to use 
> PKCS #1.5 for authentication.
> If the certificate is signed with PSS then it’s probably safe to use PSS in the signature.

That was my first thought when we came across this issue. I thought that if peer's certificate
is signed with RDASSA-PSS then it must be safe to use RSASSA-PSS in IKEv2.
To my disappointment our peer did understand certificate with PSS, but at the same time
failed to understand PSS in IKEv2. That was a sad truth of life. So, unfortunately
it doesn't reliably work.

> I know this greatly delays the deployment of PSS, because for a certificate issuer PKCS #1.5 is the safest route,
> but I don’t know that we can do better without either a negotiation or prior agreement (which just means configuration 
> from an implementer’s POV)

I don't think negotiation is needed. It's enough if each side announces its capabilities,
the same way it is done in RFC7427 with hash functions. And the easiest way to do
it is to add pseudo-hash value "RSASSA-PSS supported" into the hash algorithms registry.
In this case each side will announces that it supports some set of hash algorithms in signature and
announces whether RSASSA-PSS is supported. I understand that it is a clear protocol hack
and I don't want to follow this way, but it is the easiest path. Can you suggest better
solution (apart from "do nothing")?

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 4 Oct 2016 17:40:02 -0400 (EDT)

> solution (apart from "do nothing")?

I'm really against this solution. As you said, we can expect more of
this with ECC variants, and it will just be a large cluttering of the
integ registry.

What's wrong with adding a new notify type that can be used on the
initiator as well as on the responder? And so doesn't have the problem
of favouring the "old ways" for compatibility?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 5 Oct 2016 08:42:36 +0300

Hi Paul,

> this with ECC variants, and it will just be a large cluttering of the

I'm not happy with it either. But it is a "quick hack" that would fix this 
particular problem.

> of favouring the "old ways" for compatibility?

Nothing wrong. In my original message

https://mailarchive.ietf.org/arch/msg/ipsec/0XYpWpMrtU_IXmn_RxfWWvsXztM

I suggested three ways to deal with the problem:
1. Do nothing
2. Make a quick hack by defining a fake hash function "RSASSA_PSS" in IKEv2 Hash Algorithms registry.
3. Define new notification SIGNATURE_FORMATS that would list supported 
    signature formats

In my opinion the third option is the right way to go. However, I can leave
with the first two too. Just want to know what the WG thinks of it.

Regards,
Valery.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 5 Oct 2016 10:01:52 +0300

Perhaps we (as in the working group) should schedule some time (15-20 minutes?) to discuss the options in Seoul.

Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS signatures when they are in AUTH payloads is a pretty egregious kind of wrongness, but if this wrongness exists in the wild, we should probably come up with a strategy on how to deal with it.

Yoav

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 5 Oct 2016 10:26:40 +0300

Sure. I can prepare the slides (if the WG chairs don't mind).

Regards,
Valery.

> Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS signatures when they are
> in AUTH payloads is a pretty egregious kind of wrongness, but if this wrongness exists in the wild, we should probably
> come up with a strategy on how to deal with it.
>
> Yoav

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 5 Oct 2016 14:36:31 +0300

> this with ECC variants, and it will just be a large cluttering of the

Do you really think we will see this more in ECC? How will that happen
more in the ECC?

If I have Ed25519 key, why would someone go against the "SHOULD NOT"
in draft-nir-ipsecme-eddsa draft and use something else than Ed25519,
i.e., why would someone use Ed25519ph, or why would someone use ECDSA
with Ed25519 key (even if it would be possible). Are people really
going to mix different ECC keys with different algorithms? I would
assume it would be better to just create separete keys for each
signature algorithm, and not use the same key.

With RSA I can see the reason, as people do want to reuse the old
existing key they already have and want to use it with old RSA and
with RSASSA-PSS, but I have not yet seen reason for that in ECC.

So can you explain why you think this will happen in the ECC?
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 5 Oct 2016 15:24:52 +0300

> So can you explain why you think this will happen in the ECC?

I didn't say it would happen. I said it could happen. 

The reasons can be various. For example, after wide adoption
of EdDSA some vulnerability is found in the scheme and some 
modifications are introduced to eliminate it (analogously to 
appearance of RSASSA-PSS). Or more efficient signature
algorithm for exactly the same elliptic curve is found.

I don't know. If you asked me few years ago why would new 
RSA signature format ever appear, I wouldn't know what to 
answer and would probably agree with you that there were no reasons. 
But it happened.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 5 Oct 2016 16:38:33 +0300

> modifications are introduced to eliminate it (analogously to 

If there would be vulnerability in the signature scheme, I think we
would say you MUST NOT use the old format and you MUST use the new
format... 

> algorithm for exactly the same elliptic curve is found.

If more efficient signature algorithm is found, I would still
recommend using different keys for different methods.

> answer and would probably agree with you that there were no reasons. 

RSASSA-PSS was specified in 2003, in the RFC3447, which then obsoleted
the RFC2437, which then obsoleted the RFC2313. Both RFC2437 and
RFCC2313 were from 1998.

On the other hand the RSASSA-PSS and RSASSA-PKCS1-v1_5 both are still
defined in the RFC3447, but RSASSA-PKCS1-v1_5 was there for gradual
transition to the RSASSA-PSS:

	   Although no attacks are known
   against RSASSA-PKCS1-v1_5, in the interest of increased robustness,
   RSASSA-PSS is recommended for eventual adoption in new applications.
   RSASSA-PKCS1-v1_5 is included for compatibility with existing
   applications, and while still appropriate for new applications, a
   gradual transition to RSASSA-PSS is encouraged.

It also says:

   A generally good cryptographic practice is to employ a given RSA key
   pair in only one scheme.  This avoids the risk that vulnerability in
   one scheme may compromise the security of the other, and may be
   essential to maintain provable security.
   ...

					As another example, suppose
   an RSA key pair is employed in both RSASSA-PSS (Section 8.1) and
   RSASSA-PKCS1-v1_5.  Then the security proof for RSASSA-PSS would no
   longer be sufficient since the proof does not account for the
   possibility that signatures might be generated with a second scheme.
   Similar considerations may apply if an RSA key pair is employed in
   one of the schemes defined here and in a variant defined elsewhere.

I.e., it does recommend that one key pair is used with only one
scheme. 

So reading the RFC3447 you should not use same RSA key with both
RSASSA-PKCS1-v1_5 and RSASSA-PSS. So you are supposed to have two key
pairs one for each scheme, and then you need to pick one based on
other things, like the certificate request, ID payloads (==
configuration), or use the same key pair type than other end used.

RSASSA-PSS also appeared more than ten years ago, so it is not new,
and we have supposedly being doing transition to it for long time...

Note, that there is no way of knowing whether your certificate using
RSASSA-PSS is going to be acceptable for the other end. If it only
supports RSASSA-PKCS1-v1_5 signature method in certificates, you are
in same problem, and you have to somehow know that and use the
certificate using RSASSA-PKCS1-v1_5 signature method.

So in the initiator: do not configure RSASSA-PSS key pair before you
know that the responder can accept such key pair.

In responder: pick the key pair you are using based on the auth
payload the other end sent, or if other end did not use signatures to
authenticate, then select key based on the IDr or certificate request.
Or just add manual configuration based on the vendor ids to pick
RSASSA-PKCS1-v1_5 if you know that implementation do not support
RSASSA-PSS.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Wed, 5 Oct 2016 17:10:15 +0300

> would say you MUST NOT use the old format and you MUST use the new

That won't happen overnight anyway regardless how many MUST and MUST NOT 
we say. So the schemes will co-exist some time.

[snip]

> configuration), or use the same key pair type than other end used.

How would you do it in practice? Are you suggesting to include
the intended purpose into the DN? 

Otherwise, even if you get two certificates from single CA - one
for RSASSA-PKCS1-v1_5 and the other for RSASSA-PSS,
you cannot distinguish which to use based on certificate request
(will be the same) or ID payload (will be the same). Using the same
key pair type works only for Responder. The only workable 
option for Initiator - preconfiguration, which doesn't scale. 

> certificate using RSASSA-PKCS1-v1_5 signature method.

True. If we have something like SUPPORTED_SIGNATURE_FORMATS 
notification that this problem will also be solved - the end entity
will indicate that it supports, say, RSASSA-PSS for both IKEv2
and certificates.

> know that the responder can accept such key pair.

It works. But this approach will significantly slow down adoption of more 
secure RSASSA-PSS scheme, since RSASSA-PKCS-1.5 will be
configured "by default" by most users.

> RSASSA-PKCS1-v1_5 if you know that implementation do not support

As I've already said, I can live with "do nothing" approach you describe.
>From my point of view it is a bit more complex for implementers,
documentation (a lot of heuristics in implementations) and for configuration.
User experience will probably suffer too. Otherwise it is a valid
approach and I'm not against it. I just wonder if we (the WG)
can invent something better.

Regards,
Valery.