On Tue, 9 Nov 2021, Valery Smyslov wrote:

We can use AlgorithmIdentifier, so no new registry is needed.

Ah sorry, it does state that indeed. Although we might almost want to
not support non-RFC7427 "legacy" methods. Then again, if all software
updated and be RFC compliant, we wouldn't need this to begin with :)

But there is a trade off, so this can be discussed if the draft is adopted.

The RSS-v1.5 vs RSS-PSS is a major pain right now, and implementations
using 7425 and specifying RSA-v1.5 SHA1 are a double pain as the RFCs
clearly doesn't allow that. We run into frequent interop issues with
these.

That what this draft tries to address.

If that is the most prominent use case, then I'd rather push to fix the
implementations that dont comply to RFC 8247's:

3.2.  Digital Signature Recommendations

   When a Digital Signature authentication method is implemented, the
   following recommendations are applied for hash functions:

               +--------+-------------+----------+---------+
               | Number | Description | Status   | Comment |
               +--------+-------------+----------+---------+
               | 1      | SHA1        | MUST NOT |         |
               | 2      | SHA2-256    | MUST     |         |
               | 3      | SHA2-384    | MAY      |         |
               | 4      | SHA2-512    | SHOULD   |         |
               +--------+-------------+----------+---------+

   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.

The problem is receiving RSA-v1.5-SHA1 or RSA-PSS-SHA1 in Digital
Signatures. These are MUST NOT. I am not sure this document would
help here, as our implementation still will refuse these, even
if we are notified of this earlier.

I also still believe that "supported" is the wrong concept here. We are
really looking for "accepted".

As I said in the meeting, it becomes really tricky for the responder. It
can select a better configuration in IKE_SA_INIT based on the initiator's
information, but it is not really helping the initiator choose between
which algorithms to use as it can't really get information from the
responder in time to make a decision in IKE_AUTH unless it sent its ID
in IKE_SA_INIT in which case the responder might be able to switch to
a better configuration profile in time and share accepted authentication
methods. But I guess it won't hurt trying to get more information
across.

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to