Re: [IPsec] Interoperability problem concerning RFC 7427

["Valery Smyslov" <[e-mail]>]

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.