Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 08 Apr 2016 16:09:07 -0300

Greetings. As discussed on the list for the past few weeks, and in the 
face-to-face meeting in Buenos Aires (which, for many of us, seems to 
translate to "too much beef"), draft-ietf-ipsecme-rfc4307bis is ready 
for WG Last Call. We would like everyone to review it carefully, given 
that there have been some significant changes over the past few months.

This WG Last Call will end on April 22. It would be grand if everyone on 
this list would read the draft as if it was brand new and respond on the 
list with any problems, any questions, or even just "it is ready to 
progress as-is". Extra points are given for reviewers who don't wait 
until the last minute.

--Paul Hoffman and Dave Waltermire

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Apr 2016 01:28:45 +0200

I think this document is in very good shape, and almost ready.

The two areas where I think some more discussion may be needed are 
interoperability between IoT and "real" VPNs, and the migration to the 
RFC 7427 Digital Signature solution. See detailed comments below.

1.2: "an algorithm will be set to MAY", replace by "an algorithm will be 
denoted here as MAY".

1.2, last paragraph: I suggest to clarify what we mean by interop with 
IoT, so that we do not fragment IKE2 between the IoT and non-IoT worlds. 
Something like: "Requirement levels that are marked as "IoT" apply to 
IoT devices and to server-side implementations that might presumably 
need to interoperate with them, including any general-purpose VPN 
gateways." Maybe we should clarify it more by defining an IoT Context 
and adding separate lines to some of the tables for IoT vs. non-IoT Context.

3.3: AUTH_DES_MAC - the last sentence doesn't apply to it, so the 
paragraph needs to be rearranged.

4.1: have we considered making "Digital Signature" (#14) a SHOULD+ 
instead of a SHOULD?

4.2: aren't we trying to move the world to the generic "Digital 
Signature", even if they're still using old certs? If we are, then 
(gasp) PKCS1 v1.5 needs to be SHOULD. And the table should mention 
sha256WithRSAEncryption.

Thanks,
	Yaron

On 04/08/2016 09:09 PM, Paul Hoffman wrote:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 11 Apr 2016 15:47:11 +0300

> 4.1: have we considered making "Digital Signature" (#14) a SHOULD+ 

Yes, I think we discussed it, but I think we should really see at
least one implementation before we pick it as SHOULD+ level...

Has anybody implemented this yet?

This is still quite new, i.e., about year old, and as product cycles
tend to be quite slow in the VPN gateways, I have not yet seen any
implementations. 

> Signature", even if they're still using old certs?

Yes.

> If we are, then (gasp) PKCS1 v1.5 needs to be SHOULD.

Why? There is no relationship between the RSASSA-PSS and
RSASSA-PKCS1-v1.5 signatures in the certificates and in the AUTH
payload.

I.e., you can have RSASSA-PKCS1-v1.5 signature in the certificate, and
use the RSASSA-PSS with SHA-256 to generate the AUTH payload.

Also as we do say that RSASSA-PSS MUST be implemented, that means that
every implementation which sends out the SIGNATURE_HASH_ALGORITHMS and
conforms to this document, must support RSASSA-PSS, thus
implementations can always use it when using RSA keys.

Only reason to support RSASSA-PKCS1-v1.5 is to support RFC7427
implementations which are made before this 4307bis document came out,
and which do not support RSASSA-PSS required here.

> And the table should mention sha256WithRSAEncryption.

Which by defination is then MAY. And it is MAY because it is not using
SHA1 (which would make it SHOULD NOT), and it is using old
RSASSA-PKCS1-v1.5 which is only MAY.

We did remove all MAY lines from the table in last round.
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Apr 2016 17:05:40 +0200

Hi Tero,

Thanks for your response, I am fine with your comments but I have a 
question: in Sec. 4.2, we have: "With the use of Digital Signature, 
RSASSA-PKCS1-v1.5 MAY be implemented.  RSASSA-PSS MUST be implemented." 
And then the table has SHOULD for RSA (as well as ECDSA). How come?

Coming to think of it, if we want to ensure interoperability between 
peers that use RSA certs and peers that use ECDSA certs, then at least 
one (probably RSA) needs to be a MUST, even if people are using RFC7427.

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 12 Apr 2016 12:16:28 +0300

> And then the table has SHOULD for RSA (as well as ECDSA). How come?

RSASSA-PSS MUST be implemented if Digital Signature authentication
method is implemented, but it can be implemented with multiple hash
algorithms. On the other hand in hash algorithms part we have just one
MUST and that is for SHA2-256.

The reason why RSASSA-PSS with SHA-256 is listed only as SHOULD, is
mostly caused by the fact that Digital Signature authentication method
is still onl SHOULD and we do not have implementations for it, so we
do not have implementor comments for it yet.

So Digital Signature in general is SHOULD.

SHA2-256 as hash algorithm is MUST when implementing Digital Signature
authentication method.

RSASSA-PSS is MUST when implementing Digital Signature.

That would actually make RSASSA-PSS with SHA-256 a effective MUST, if
Digital Signature is in general supported, but we do not label it as
MUST as complient implementation can still decide not to implement
digital signatures at all. 

> one (probably RSA) needs to be a MUST, even if people are using RFC7427.

Usually this is not a problem, i.e., in normal use the configuration
has just one private key (either rsa or ECDSA) and that is what is
used. If you have ECDSA private key and they implementation does not
support ECDSA, you cannot use that implementation, you need to pick
another implementation. The other end of the configuration is also
configured to trust your private key (either by config, or through
CA), and if it cannot support your private key type you cannot really
configure it that way. I.e., the implementation requirements do not
come from this document, they came from the pre-existing
authentication infrastructure and private keys users have.

Anyways when we make Digital Signature authentication method a MUST,
we can also make RSASSA-PSS with SHA-256 a MUST.

The question there is should we already mark this fact by making it
now SHOULD+, as we do expect it to be next mandatory to implement
algorithm if Digital Signature authentication method really gets
deployed?
-- 
[email-masked]

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 13 Apr 2016 17:37:49 +0300

> algorithm if Digital Signature authentication method really gets

IMHO, yes.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 Apr 2016 10:40:43 -0400 (EDT)

>>  algorithm if Digital Signature authentication method really gets

I dont think we should make anything a SHOULD+ that we have not seen
interoperate in the wild. In fact, even a SHOULD is pushing it already,
but we really do want to push it in this case.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Apr 2016 17:22:01 +0300

Hi, 

Yes.

> and which do not support RSASSA-PSS required here.

I don't think it is a good idea in general to link support for RSASSA-PSS with 
support for RFC7427. However, I don't know a better solution for now.
I think it is a deficiency of RFC7427 that it only allows to indicate the list
of supported hash functions and doesn't allow to indicate supported
signature formats. 

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 Apr 2016 17:30:18 +0300

Hi, 

> RSASSA-PSS is MUST when implementing Digital Signature.

All these thing are not clear from the current text of the draft.
I was also confused as well as Yaron. 

As I've said in previous message, I'm not a fan of idea to tie support for RSASSA-PSS 
with support for Digital Signature auth. Nevertheless if this link is imposed
by the draft, it must be spelled out more clearly.

Regards,
Valery.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 14 Apr 2016 14:53:55 +0000

Hi Paul and all,

1) All of the DH-groups smaller than 2K in the table 3.4 must not be used because they are not strong enough. Right now, groups 5, 2 and 22 are being listed as "should not" which means that  "must not use unless a user has a strong reason". The problem is that a user can always have a strong reason because there is no definition of "a strong reason".

The group 2 (1K DH group) is currently mandatory-to-implement; therefore, implementers must implement it for interop. reason. But, the problem is that the draft is also for users. So, there are two problems. The first one is that the working group should update the standard to mandate a stronger DH group (or a ECC group) (which is hard to get done soon). And, the second (which is urgent) is that the draft should explicitly say that "users must not use those weak groups".

The fact that many existing devices are still using the group 2 ( 1K DH group) does not make the group secure. The document should provide sound technical guidelines for users. If a user still chooses to use a weak group, that would be his/her own fault.

2) Similarly for RSA sizes smaller than 2K and digital signatures using SHA1,  "should not" should become "must not".

Regards,
Quynh.

________________________________________
From: IPsec <[email-masked]> on behalf of Paul Hoffman <[email-masked]>
Sent: Friday, April 8, 2016 3:09:07 PM
To: IPsecME WG
Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

---

From: [email-masked]
Date: Thu, 14 Apr 2016 11:22:05 -0400 (EDT)

> The group 2 (1K DH group) is currently mandatory-to-implement; therefore, implementers must implement it for interop. reason. But, the problem is that the draft is also for users. So, there are two…

The draft is not for users. It is also not for default values. This is
explained at

https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-07#section-1.3

    The recommendations of this document mostly target IKEv2 implementers
    as implementations need to meet both high security expectations as
    well as high interoperability between various vendors and with
    different versions.  Interoperability requires a smooth move to more
    secure cipher suites.  This may differ from a user point of view that
    may deploy and configure IKEv2 with only the safest cipher suite.  On
    the other hand, comments and recommendations from this document are
    also expected to be useful for such users.

Removing group 2 an 5 is expected to cause interoperability issues
because not everyone switch to group 14 for IKEv2 and not everyone
properly implements INVALID_KE and restarting with a different
DH group.

I would also not call group 5 (1536) "weak".

> The fact that many existing devices are still using the group 2 ( 1K DH group) does not make the group secure. The document should provide sound technical guidelines for users. If a user still choo…

The user can only make that fault if the implementations still support
those DH groups.

> 2) Similarly for RSA sizes smaller than 2K and digital signatures using SHA1,  "should not" should become "must not".

And what percentage of certificate based VPN connections would break?
I suspect more than 75%

Many deployments actually kept away from 2048 bit RSA because it causes
IKE fragmentation (RFC-7383) was only added to IKEv2 in November 2014.
Give implementors 1 year, then add a year for just missing fresh 1024
bit certificates, and you are at the start of 2017. So I don't think
we can say MUST NOT for RSA 1024 bit keys.

Paul

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Thu, 14 Apr 2016 17:21:53 +0000

Paul,

I just copied from your quote in section 1.3 here: "This may differ from a user point of view that may deploy and configure IKEv2 with only the safest cipher suite.  On the other hand, comments and recommendations from this document are also expected to be useful for such users."

We should be clear about recommendation for interoperability reason and recommendation for security reason: they are different.

Quynh. 
________________________________________
From: IPsec <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Thursday, April 14, 2016 11:22 AM
To: Dang, Quynh (Fed)
Cc: IPsecME WG; Paul Hoffman; Frankel, Sheila E. (Fed)
Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-rfc4307bis

Paul

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Apr 2016 17:01:56 +0300

> > Has anybody implemented this yet?

Good to know. Do you know if there has been any interoperability tests
with it? 

> > Also as we do say that RSASSA-PSS MUST be implemented, that means
> > that every implementation which sends out the
> > SIGNATURE_HASH_ALGORITHMS and conforms to this document, must
> > support RSASSA-PSS, thus implementations can always use it when
> > using RSA keys.
> > 
> I don't think it is a good idea in general to link support for
> RSASSA-PSS with support for RFC7427. However, I don't know a better
> solution for now.

To provide interoperability we need to pick some signature methods as
mandatory to implement for the RFC7427 in the future, and my guess is
that it will be RSASSA-PSS. 

> I think it is a deficiency of RFC7427 that it only allows to
> indicate the list of supported hash functions and doesn't allow to
> indicate supported signature formats.

The RFC7427 explains why this is not needed in section 5, and we had
discussion about this when the RFC was being written.

In general this is not usually a problem, as quite often the initiator
has one private key configured, and this is what he will be using for
the specific server. I.e., the public key type is known from the
configuration. The responder will simply pick the same type of key
than the initiator used.

I.e., it is not normally question whether the other end implements
certain public key method, it is more or less question whther the
private / public key will be accepted by the other end in the
configuration.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Apr 2016 17:05:18 +0300

> I was also confused as well as Yaron. 

Why the following text is not clear enough:

   With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be
   implemented.  RSASSA-PSS MUST be implemented.

I think it very clearly says that RSASSA-PSS MUST be implemented when
Digital Signature authentication method is implemented. 

> As I've said in previous message, I'm not a fan of idea to tie
> support for RSASSA-PSS with support for Digital Signature auth.
> Nevertheless if this link is imposed by the draft, it must be
> spelled out more clearly.

And you think the paragraph above is not clear enough? If not then
provide text that will say it even more clearly.
-- 
[email-masked]

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Apr 2016 10:13:42 +0300

> provide text that will say it even more clearly.

Section 4.2:

Old:
   Recommendations for when a hash function is involved in a signature:

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

(stress that this table is concerned only with Digital Signature Authentication method).

Old:

New:
    When Digital Signature authentication method is used with RSA signature
    algorithm, then RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 
    MAY be supported.

(stress that this requirement is applied to RSA only, not to ECDSA etc.)

Old:
   Recommendation of Authentication Method described in [RFC7427]
   notation:

       +------------------------------------+------------+---------+
       | Description                        | Status     | Comment |
       +------------------------------------+------------+---------+
       | RSASSA-PSS with SHA-256            | SHOULD     |         |
       | ecdsa-with-sha256                  | SHOULD     |         |
       | sha1WithRSAEncryption              | SHOULD NOT |         |
       | dsa-with-sha1                      | SHOULD NOT |         |
       | ecdsa-with-sha1                    | SHOULD NOT |         |
       | RSASSA-PSS with Empty Parameters   | SHOULD NOT |         |
       | RSASSA-PSS with Default Parameters | SHOULD NOT |         |
       +------------------------------------+------------+---------+

New:
    The following table lists recommendations for authentication methods 
    in [RFC7427] notation. These recommendations are applied only if 
    Digital Signature authentication method is implemented.

       +------------------------------------+------------+---------+
       | Description                        | Status     | Comment |
       +------------------------------------+------------+---------+
       | RSASSA-PSS with SHA-256            | MUST     |         |
       | ecdsa-with-sha256                  | SHOULD     |         |
       | sha1WithRSAEncryption              | SHOULD NOT |         |
       | dsa-with-sha1                      | SHOULD NOT |         |
       | ecdsa-with-sha1                    | SHOULD NOT |         |
       | RSASSA-PSS with Empty Parameters   | SHOULD NOT |         |
       | RSASSA-PSS with Default Parameters | SHOULD NOT |         |
       +------------------------------------+------------+---------+

(RSASSA-PSS with SHA-256 changed to MUST, so that there is no confusion
with the above statements, but at the same time the text added clarifying that 
these recommendations are only applicable if Digital Signature auth is implemented,
which is SHOULD according to the table 6).

Regards,
Valery.

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Apr 2016 10:38:12 +0300

Hi, 

> Good to know. Do you know if there has been any interoperability tests

We are interoperable with ourselves (not a surprise) and with strongSwan
(no RSASSA-PSS was tested yet though).

> discussion about this when the RFC was being written.

No. it was different discussion. We discussed the situation 
when peers have several private keys for different algorithms
(say RSA and ECDSA) and the way they select the proper one.

Now consider the situation when a host has a single key pair for RSA.
However, it can either prepare RSASSA-PKCS1-v1.5 signature
or RSASSA-PSS signature. The problem is that the host
doesn't know if its peer supports RSASSA-PSS or not and RFC7427 
doen't allow peers to indicate what formats are supported - only hashes 
are exchanged.

In your draft you artificially link Digital Signature auth with
support for RSASSA-PSS, so if you support Digital Signature authentication
them you MUST support RSASSA-PSS. I understand that this is probably
the only possible solution for now, but in general this linkage is not a good thing.
If tomorrow RSASSA-PSS is updated and a new uncompatible RSASSA-PSSv2
is adopted, then how will the peers indicate that this new format 
is supported? We'll have a lot of interoperability issues...

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Apr 2016 14:21:32 +0300

> > provide text that will say it even more clearly.

These changes looked good. And I think we should do those (unless
someone objects).

The WGLC ends by the end of this week, so we will make new version
after it finishes (so we can do all WGLC changes at the same time).
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Apr 2016 14:51:26 +0300

> doen't allow peers to indicate what formats are supported - only hashes 

My original idea was that while changing to the RFC7427 everybody
would also move to the RSASSA-PSS and PKCS1-v1.5 would be obsoleted at
that point. I.e., if you implement RFC7427 you should also get the RSA
updated to the safer version.

I mean if you are using RSASSA-PKCS1-v1.5 you can use old
authentication method, the RFC7427 support is needed for RSASSA-PSS.
And RSASSA-PKCS1-v1.5 has some issues. This is described in the
RFC7427 Introduction and Security Considerations sections.

> support for RSASSA-PSS, so if you support Digital Signature
> authentication them you MUST support RSASSA-PSS. I understand that
> this is probably the only possible solution for now, but in general
> this linkage is not a good thing. If tomorrow RSASSA-PSS is updated
> and a new uncompatible RSASSA-PSSv2 is adopted, then how will the
> peers indicate that this new format is supported? We'll have a lot
> of interoperability issues...

If RSASSA-PSSv2 is done because RSASSA-PSS is found broken, then we
just mark RSASSA-PSS as MUST NOT, and move to the new version.

Anyways the reason why there is no negotiation for the private key
type or signature algorithm other than hash is that the IKE_SA_INIT
exchange needs to be kept short so adding too my negotiation stuff
there is bad idea. This was discussed when the RFC7427 was being
written.

The original idea was to support ECDSA, and RSASSA-PSS was more or
less a side-product from the final design. But it was still
side-product that people wanted to keep. We also did not allow
negotiating other parameters in the RSASSA-PSS [1].

You did propose making negotiation more complex [2] during the WGLC of
RFC7427, but as you can see from my reply [3] it would get really
complicated then. Then in the end of that discussion we didn't make
any changes to the document.

[1] https://www.ietf.org/mail-archive/web/ipsec/current/msg08027.html
[2] https://www.ietf.org/mail-archive/web/ipsec/current/msg08671.html
[3] https://www.ietf.org/mail-archive/web/ipsec/current/msg08673.html
-- 
[email-masked]

---

From: [email-masked]
Date: Tue, 19 Apr 2016 09:23:29 -0400 (EDT)

>>  provide text that will say it even more clearly.

I think all these changes are good. If I don't hear any objections in
the next day or so of the co-authors, I'll push them through.

Paul

>    algorithm, then RSASSA-PSS MUST be supported and RSASSA-PKCS1-v1.5 MAY be
>    supported.
>
>    The following table lists recommendations for authentication methods in
>    [RFC7427] notation. These recommendations are applied only if Digital
>    Signature authentication method is implemented.
>
> with the above statements, but at the same time the text added clarifying 
> that these recommendations are only applicable if Digital Signature auth is 
> implemented,

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 19 Apr 2016 17:05:59 +0300

> just mark RSASSA-PSS as MUST NOT, and move to the new version.

And this will cause interoperability problems since there is no way for the peers 
to indicate each other that they support particular signature encoding.
"MUST NOT" in RFC is insufficient: in real life you cannot update
all implementations overnight. Well, this is just a grunt...

---

From: "Graham Bartlett (grbartle)" <[email-masked]>
Date: Wed, 27 Apr 2016 19:24:27 +0000

Hi Valery

Sorry for the late reply. To answer your Q - sort of.. But I¹ve a few new
ideas since on minimising the impact for the small devices.

I¹ll be in touch with these..

cheers