Subject: [IPsec] Agenda for IETF 100

From: Sahana Prasad <[email-masked]>
Date: Thu, 2 Nov 2017 12:25:22 +0100

Hello,

We could consider adding this item to the working charter :

Explicitly negotiating different RSA versions (Specific case) :

According to section 3.2 of rfc-8247 (was rfc-4307 bis) ,it is mentioned
that :

  "  When the Digital Signature authentication method is used with RSA
     signature algorithm, RSASSA-PSS MUST be supported and RSASSA-
     PKCS1-v1.5 MAY be supported  "

However , the way to signal to the peer which version of RSA is being used
is  neither mentioned  in rfc-7427 nor in rfc-8247.
Right now there is no way to fallback from RSASSA - PSS to
RSASSA-PKCS1-v1.5 or vice-versa. (Ideally since RSASSA-PSS MUST be
supported on both ends with Digital signatures implemented, the fallback
case should not arise. Then why is there a need to still support the older
version of RSASSA-PKCS1-v1.5  (the MAY case) ? )
Since the rfc-8247 clearly mentions that there should be a MUST and a MAY
case, there should also be clarity on how to switch between the two methods.

A more general case:

Please note that RSASSA-PSS is just a specific case but the root of the
problem is that while the peers announce their list of hashes they support
for using Digital Signatures, there is no explicit way for them to announce
the supported list of signature formats. Earlier this was not a problem because
there was only one signature format (RSA-PKCS#1). But now, we have newer
RSASSA-PSS Signature formats and therefore the problem. We can probably
envision that the number of signature formats will grow (newer Edward
signatures, even more newer hash-based signatures etc.), so we expect that
the specific problem with RSASSA-PSS won’t be the only problem with
signature formats.

Thank you.

Regards,

Sahana Prasad

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 2 Nov 2017 17:48:50 +0200

> Explicitly negotiating different RSA versions (Specific case) :

If you want it to be considered as charter item, please provide text
suitable for charter. 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 2 Nov 2017 21:25:15 +0300

Hi Tero,

how about:

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.
A prominent example is RSASSA-PKCS#1 and RSASSA-PSS, however
it is envisioned that the same situation may repeat in future
with other signature algorithms. Currently IKE peers have no explicit way 
to indicate each other which signature format(s) the support, that leads 
to ineroperability problems. The WG will investigate the situation 
and come up with a solution that allows peers to deal with the problem
in an interoperable way.

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 3 Nov 2017 03:57:16 +0200

> and come up with a solution that allows peers to deal with the problem

You know what I personally think about this, but as chair I have to
say, added to the list of candidate items...
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Nov 2017 02:20:10 -0400 (EDT)

On Thu, 2 Nov 2017, Valery Smyslov wrote:

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

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 5 Nov 2017 19:37:06 +0200

> 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-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 6 Nov 2017 10:32:54 +0300

Hi Tero,

> use, and I would say that is configuration error in the server side.

Well, if we are talking about the specific product we ran into interoperability
problem with, then its behavior is a bit different. It does support 
RSASSA-PSS signatures in certificates, however it cannot use RSASSA-PSS 
signatures in IKE. I guess that the reason for such behaviour is because 
the certificate processing (including signature verification) is performed by 
some cert lib, while IKE signature forming/verification is performed by another 
piece of code.

> use when it connects to which server.

There is no indication in certificate that the public key it contains
must be used explicitely with RSASSA-PKCS#1 or RSASSA-PSS.
So, the client does know which certificate to us, it doesn't know
which form of signature to use.

> making sure server sides are updated before clients, 

There are use cases when both peers can act as initiator and responder (SG-SG).

> or using separate CA for different key types. 

Very inconvenient.

> Another case where this might happen when

I think that is true only for HTTPS use case, when TLS client is preconfigured
with a bunch of trusted CAs and the authentication is performed one-way.
Is not true for TLS in general.

> issue without doing protocol changes.

No, section 5 is about a different problem: how to select 
a proper certificate, if we have several certificates containing
public keys for different signature algorithms. 

Now we have the only certificate (or raw key), but we don't
know how to use it, because there are more than one way of 
using it and the peer doesn't inform us what it supports.

> this issue is disappears.

In some cases it can be solved by additional configuration option,
but I dont't think in all. The other option for initiator is to retry
IKE SA in case it receives AUTHENTICATION_FAILED. But it is 
very bad option and I'd rather resolve it by protocol means.

RSASSA-PSS is just a specific problem we ran into, I suspect
we can have the same sort of problem in future with other signature
algorithms, provided their number is nowdays increasing
rapidly.

Regards,
Valery.

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Nov 2017 09:30:52 +0200

> public keys for different signature algorithms. 

Not true. It is how to select public key algorithm to use, and that
boils down selecting suitable private/public key pair from your own
private / public key pairs. When you have selected your private key
you want to use that will then dicatate which public key you are going
to using and also the certificate you are going to use.

Even if you can use same private key for PKCS#1 and RSA-PSS, does not
mean that you should do it. Using same key for different algorithms
breaks the key separation principle, and I think that is considered
bad idea.

> using it and the peer doesn't inform us what it supports.

When you are generating the signature you have private key, and that
should have algorithm associated to it... So when you select public
key that will have one private key associated with it that has one
algorithm associated to it etc.

> algorithms, provided their number is nowdays increasing

If I remember right on discussion about the different elliptic curve
algorithms, the situation was same there, i.e., even if you could use
the same key for different algorithms, it is considered bad idea... 
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Nov 2017 11:20:01 +0300

> the same key for different algorithms, it is considered bad idea...

We are not talking about different algorithms. Consider the situation
when the same signature can we represented in a different ways
(e.g. different ASN.1 encodings).
In this case we'll run into the problem if one of the peers supports
only one way.

The only reliable way for the initiator to select a proper form of signature
now is pre-configuration. But it doesn't scale well and is problematic
with opportunistic encryption. 

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 14 Nov 2017 10:57:34 +0200

> In this case we'll run into the problem if one of the peers supports

Why would you make multiple encodings formats for the same algorithm?
And if so why should we allow that in IPsec. We do not allow prehashed
formats of the Ed25519 and Ed448 because we do not want to have
multiple formats for the same thing.

> with opportunistic encryption. 

It is same with PSKs or IP addresses / DNS names. You need to
pre-configure the PSK to be used and to which IP address (or DNS name)
to connect... IPsec normally do require some pre-configuration before
it can be used (with exception to the opportunistic encryption).
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 14 Nov 2017 12:09:10 +0300

> multiple formats for the same thing.

If tomorrow cryptographers discover some weakness in one encoding
and start recommend using another format, then we'll have to follow.
And it doesn't matter if we disallowed using it before.

> it can be used (with exception to the opportunistic encryption).

Some pre-configuration is inevitable. But let's try to keep it minimal - 
it helps maintain algorithm agility in large scale.

---

From: Tero Kivinen <[email-masked]>
Date: Wed, 15 Nov 2017 05:20:26 +0200

> And it doesn't matter if we disallowed using it before.

In such case you do create a new key, and you do disable the old
format, so there is no issue with this, as you still have only one
format for a key.

> it helps maintain algorithm agility in large scale. 

Yes, but configuring the authentication credentials (PSK, or private
key to be used) for each remote host is something that I do expect to
be done in future too.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 16 Nov 2017 04:51:41 +0300

> format, so there is no issue with this, as you still have only one

I'm not so sure about the future movements in cryptography :-)

Nevertheless, even if it is a different key,
it'll most probably be issued by the same CA, so the initiator will have no 
clue how to select the proper key apart from pre-configuration
(CERTREQUEST won't help). And pre-configuration won't work
is case of opportunistic encryption and in will work badly in
large scale. We still have a problem.