Hi Tero,
[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
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]
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.
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.
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.
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.
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.
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...
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.
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.
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
It is a bit different issue. And it is practical.
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.
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.
I do not think this is issue for ECDSA or EdDSA. And
draft-nir-ipsecme-eddsa-01 says that *ph SHOULD ONT be used...
Not so sure...
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
