[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] Comments on draft-smyslov-ipsecme-ikev2-auth-announce
From:       Paul Wouters <paul () nohats ! ca>
Date:       2021-11-10 1:03:47
Message-ID: b25c5ff-7fe-3293-a7ab-13642fcde0ca () nohats ! ca
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]