Subject: Re: [IPsec] RFC4307bis working version 3

From: Johannes Merkle <[email-masked]>
Date: Wed, 10 Feb 2016 10:46:17 +0100

> Please find the working version of version 03:
> https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c
> Feel free to provide comments.

Given the difficulty and time needed to deprecate cryptographic algorithms, I advocate to disallow DSS for
authentication. It is not widely deployed, anyway.

And for the digital signature method, why should we require SHA-1?

-- 
Johannes

---

From: Paul Wouters <[email-masked]>
Date: Wed, 10 Feb 2016 06:43:58 -0500 (EST)

>> Feel free to provide comments.

Note we should reference it via:

https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-03

> authentication. It is not widely deployed, anyway.

We cannot "disallow" it as it might be in use today. The idea is these
series of drafts move things from SHOULD to SHOULD+ to MUST to MUST-
to SHOULD NOT to MUST NOT. We are trying to phase things in and out
smoothly unless there are strong reasons to speed up this process.

> And for the digital signature method, why should we require SHA-1?

Because it is very common to use right now. We cannot go from MUST to
MUST NOT.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Wed, 10 Feb 2016 16:48:05 +0200

> Because it is very common to use right now. We cannot go from MUST to

No, but RFC 4307 says nothing about hashes in signatures (whether RSA(1) or digital signature(14)). So whatever we recommend here is new.

This is even more true for digital signature(14) as we hardly have any legacy code to maintain backwards compatibility with[1].

Also, unlike in TLS, we did not tie signature algorithms in certificates to signature algorithms in the protocol, so it’s fine to insist on SHA2-256 in the protocol while accepting SHA1 in the certificate. At least it’s fine as far as IKE goes. This is important because there are all kinds of certificates and CAs that we have to work with, but I don’t believe there is any modern IKE implementation (definitely not one that has implemented RFC 7427) that does not support SHA2-256 at least.

So ISTM that we should be fine recommending SHA2-256 at the MUST level with SHA1 in the SHOULD NOT level (to allow people who manage to interface old hardware modules to new IKE software)

Yoav

[1] "legacy code with which to maintain backwards compatibility"?

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 11 Feb 2016 14:04:17 +0200

Yoav Nir writes:
> No, but RFC 4307 says nothing about hashes in signatures (whether
> RSA(1) or digital signature(14)). So whatever we recommend here is
> new.

There are two issues there.

The RFC7296 says that SHA-1 is SHOULD for RSA Digital Signatures in
section 3.8:

   RSA Digital Signature                  1
      Computed as specified in Section 2.15 using an RSA private key
      with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1]
      (implementers should note that IKEv1 used a different method for
      RSA signatures).  To promote interoperability, implementations
      that support this type SHOULD support signatures that use SHA-1
      as the hash function and SHOULD use SHA-1 as the default hash
      function when generating signatures.  Implementations can use the
      certificates received from a given peer as a hint for selecting a
      mutually understood hash function for the AUTH payload signature.
      Note, however, that the hash algorithm used in the AUTH payload
      signature doesn't have to be the same as any hash algorithm(s)
      used in the certificate(s).

So for RSA Digital Signatures the SHA-1 was SHOULD, and I think it
should still be SHOULD for that, as that is the algorithm everybody
are using. Also note, that there is no negotiation for the signature
algorithm there, thus if one end picks SHA2-256 and other end does not
support it the authentication will simply fail, and there is no way to recover.

On the other hand we should be downgrading that method completely over
the generic Digital Signature method specified in RFC7427.

When using RFC7427 signature there is negotiation for the signature
algorithm, providing the algorithm agility. I.e. in that case it is
safe to propose SHA-1, SHA-256 etc and then both ends pick one of the
algorithms other end supports.

For RFC7427 support there is no point of requiring MUST for SHA-1 as
all of RFC7427 implementations are new, and they should support SHA2
based algorithms too. I.e. It would be better to say SHA-1 for RFC7427
for SHOULD NOT, and SHA2-256 for MUST. The RFC7427 support is still
only SHOULD...

> This is even more true for digital signature(14) as we hardly have
> any legacy code to maintain backwards compatibility with[1].

Yes.

> So ISTM that we should be fine recommending SHA2-256 at the MUST
> level with SHA1 in the SHOULD NOT level (to allow people who manage
> to interface old hardware modules to new IKE software)

Agree for RFC7427. For Old RSA Digital Signatures SHA-1 is the one
that is still used, and I think we should keep that SHOULD- or
similar.
-- 
[email-masked]