Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

[John Mattsson]

Some comments on draft-ietf-ipsecme-rfc4307bis-00

In general, very good and very needed.


- Abstract says:
“This document defines the current set of algorithms that are mandatory to 
implement as part of IKEv2, as well as algorithms that should be implemented 
because they may be promoted to mandatory at some future time.”

The introduction also only talks about MTI and believed to be future MTI. 
ENCR_DES does not fit in either of these categories. I am all for specifying 
MUST NOT for such algorithms, but the abstract and introduction should be 
updated.


- BTW, What does it mean that an algorithm like ENCR_RC5 is not listed, does 
that mean “MAY”, “MUST NOT”, or “totally unspecified”?


- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is used, no 
algorithm from this table needs to be used.” Shouldn’t this be “MUST NOT be 
used”.


- Section 3.1. I think AES_CCM_8 should somehow be restricted to IoT, as using 
64 bit tags in IKE does not sound like general good advise. Also IoT 
implementations would probably just implement “ENCR_AES_CCM_8”, 
“PRF_HMAC_SHA2_256", and "256-bit random ECP group" and skip everything else. 
It seem to make more sense to specify an IoT profile in a separate section.


- Section 3.4. The Diffie-Hellman group table diverges heavily from the rest 
with only 112-bit security as MUST, and no group offering 128-bit security as 
even SHOULD+. This may be ok, but I think the ipsecme group should try to 
fulfill general recommendations on security levels (NIST, ECRYPT) and have a 
plan on how to make 2048-bit MOPD a MUST NOT before 2030. Not being able to 
forbid 1024-bit MOPD is this draft is a failure, let’s not repeat it.


- At least “AES-XCBC-PRF-128” and “256-bit random ECP group” should have 
references to point out which of the RFCs that are MTI.


Cheers,
John

-
John Mattsson
MSc Engineering Physics, MSc Business Administration and Economics
Ericsson IETF Security Coordinator 
Senior Researcher, Security

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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Yoav Nir]

> On 3 Nov 2015, at 1:33 PM, Tero Kivinen  wrote:
> 
> Yoav Nir writes:
>> There is 1 for “RSA Digital Signature” and you can encode any hash
>> function the you would like, but for ECDSA there is: 
>> 9 - ECDSA with SHA-256 on the P-256 curve
>> 10 - ECDSA with SHA-384 on the P-384 curve
>> 11 - ECDSA with SHA-512 on the P-521 curve
> 
> Also number 3 DSS Digital Signature uses a SHA-1 hash
> 
>> So unless you go by RFC 7427, you can’t mix and match.
> 
> So everybody should move to use that :-)

It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So you 
couldn’t fit the output of SHA-384 in there. It does work the other way around 
(SHA-256 and P-384), but I’m not sure whether that is any more secure than 
SHA-256 with P-256.

Yoav

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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Dan Harkins]

On Mon, November 2, 2015 8:58 pm, Yoav Nir wrote:
>
>> On 3 Nov 2015, at 1:33 PM, Tero Kivinen  wrote:
>>
>> Yoav Nir writes:
>>> There is 1 for “RSA Digital Signature” and you can encode any hash
>>> function the you would like, but for ECDSA there is:
>>> 9 - ECDSA with SHA-256 on the P-256 curve
>>> 10 - ECDSA with SHA-384 on the P-384 curve
>>> 11 - ECDSA with SHA-512 on the P-521 curve
>>
>> Also number 3 DSS Digital Signature uses a SHA-1 hash
>>
>>> So unless you go by RFC 7427, you can’t mix and match.
>>
>> So everybody should move to use that :-)

  Yes, they should! Note that the repository uses a definite
article (and we all know which curves the authors were referring
to). So you can't do #9 with the brainpoolp256 curve, which is
sub-optimal.

> It could work for DSA. ECDSA with P-256 gets as input a 256-bit number. So
> you couldn’t fit the output of SHA-384 in there. It does work the other
> way around (SHA-256 and P-384), but I’m not sure whether that is any
> more secure than SHA-256 with P-256.

  That's why X9.62 specifies using the left-most length of
prime bits when the digest is larger than the length of the
prime. It does work. Technically you can use ecdsa-with-SHA384
and "the P-256 curve", why you would want to is a different
story.

  Odd fact: the WAPI protocol (Chinese wireless encryption and
authentication protocol) uses SHA-256 with a special Chinese
government-specified curve based on a 192-bit prime and doesn't
follow X9.62. It uses the entire 256 bit digest to calculate the
signature on the 192-bit curve. The 256-bit digest does "fit"
since the math is all mod p. The result (r,s) is properly formed
but s will be different from a standard ECDSA signature.

  Dan.



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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Yoav Nir]

> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer  wrote:
> 
> If not here, where does this advice go?
 
 I see your point. But for instance for X509 certificates, I really would
 like to not make any statement and point to whatever equivalent of PKIX
 documents there are on that. Does the TLS WG have any documents on
 crypto agility for PKIX?
>>> 
>>> The TLS list currently has a thread about whether TLS 1.3 should prohibit 
>>> SHA-1 only in signatures or also in the certificate chain.
>> 
>>  https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E
>>> 
>>> It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol 
>>> (CertificateVerify message), and current spec prohibits server certificate 
>>> signed with SHA-1 (only EE certificate) when another certificate exists.
>>> 
> 
> For TLS, the industry is moving faster than the WG on this. Chrome warnings 
> are causing people to migrate to all-SHA256 certificate chains soon. IKE 
> often works with custom certs and private CAs, so the IPsec community needs 
> to set its own standards.

Chrome is both a TLS implementation and a PKIX relying party. The question 
there is not whether signing intermediate certificates with SHA-1 is good or 
bad. It’s definitely bad. These chains ought to be rejected. The only question 
is whether such advice belongs in the TLS spec or some PKIX document 
(tentatively named “SHA-1 die, die, die”)

As for IKE, yes we often work with private CAs, but if those CAs sign 
certificates with SHA-1, it would make it as easy to forge as if they were 
public CAs. Issuance usually involves generating a certificate request and 
running an enrollment protocol, no matter how many layers of pretty purple GUI 
my employer hides this under.

So if your private CA signs with SHA-1, it should be modified to sign with 
something better, just as it should have been modified to issue certificates 
with 2048-bit RSA rather than 1024-bit. Just like TLS, we can specify 
requirements on the certificates in an IPsecME spec, or we can rely on PKIX 
best practices. But what algorithm is used in the AUTH payload? That’s entirely 
up to us.

Yoav

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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Yaron Sheffer]

If not here, where does this advice go?


I see your point. But for instance for X509 certificates, I really would
like to not make any statement and point to whatever equivalent of PKIX
documents there are on that. Does the TLS WG have any documents on
crypto agility for PKIX?


The TLS list currently has a thread about whether TLS 1.3 should prohibit SHA-1 
only in signatures or also in the certificate chain.


https://mailarchive.ietf.org/arch/msg/tls/-1LxtUHZTQXvvMVsLR4jzp79q9E


It’s not decided yet, but they *are* prohibiting SHA-1 in the protocol 
(CertificateVerify message), and current spec prohibits server certificate 
signed with SHA-1 (only EE certificate) when another certificate exists.



For TLS, the industry is moving faster than the WG on this. Chrome 
warnings are causing people to migrate to all-SHA256 certificate chains 
soon. IKE often works with custom certs and private CAs, so the IPsec 
community needs to set its own standards.


Thanks,
Yaron

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

[John Mattsson]

On 03/11/15 09:42, "Tero Kivinen"  wrote:


>>- Section 3.2. says “When an AEAD algorithm (see Section 3.1) is
>> used, no algorithm from this table needs to be used.” Shouldn’t this
>> be “MUST NOT be used”.
>
>This document just states the fact, the actual MUST NOT is in the
>RFC5282, and I do not think we should repeat that here. I.e. this text
>just states the fact of life based on the RFC5282, but does not make
>any requirements.

Then you should probably remove the ‘MUST' in "Algorithms that are not
AEAD MUST be used in conjunction with the integrity algorithms in Section
3.2.”


>>- Section 3.1. I think AES_CCM_8 should somehow be restricted to
>> IoT, as using 64 bit tags in IKE does not sound like general good
>> advise. Also IoT implementations would probably just implement
>> “ENCR_AES_CCM_8”, “PRF_HMAC_SHA2_256", and "256-bit random ECP
>> group" and skip everything else. It seem to make more sense to
>> specify an IoT profile in a separate section.
>
>The IoT devices talk to each other, but also to more general purpose
>servers, i.e., in your home you might have some kind home area network
>server, where all the IoT devices connect to. In that case those
>bigger boxes do want to implement the same AES_CCM_8 just so that
>those IoT devices which didn't implement anything else can talk to
>them.
>
>I.e. I think it is good thing to require real systems to have SHOULD
>for the AES_CCM_8. Of couse if your implementation is never expected
>to talk to IoT devices, then that is good reason to go against the
>SHOULD and leave the AES_CCM_8 implementation out.

That sound reasonable, but shouldn’t the IoT devices have some guidelines
(maybe just a sentence) on what they should implement? We know that they
will not implement everything, and if they chose different subsets, they
will not be able to talk to each other.

>>- Section 3.4. The Diffie-Hellman group table diverges heavily from
>> the rest with only 112-bit security as MUST, and no group offering
>> 128-bit security as even SHOULD+.
>
>That depends how you calculate the securities of the Diffie-Hellman
>groups. If you check RFC3526 that gives two strengh estimates for
>2014-bit group, 110 and 160 bits. The 160 bit strength takes also
>account the memory prices in the calculations, the 110 assumes memory
>is free, and CPU cost is only thing that matters.

There is also:
- Lenstra (http://infoscience.epfl.ch/record/164539/files/NPDF-32.pdf)
giving the estimate 95 bit strength
- The IETF BCP (RFC3766) giving the estimate 103 bit strength
- ECRYPT giving the estimate 103 bit strength

So if anything, I would say the general consensus is that 2048 MODP may
not even give 112 bits security…

>>This may be ok, but I think the ipsecme group should try to fulfill
>> general recommendations on security levels (NIST, ECRYPT) and have a
>> plan on how to make 2048-bit MOPD a MUST NOT before 2030.
>
>I think we are going to replace this document several times before
>2030. We actually should have replaced this already few years ago, so
>this update is already bit late, but I would assume we might make new
>version after we get those new EC groups now being defined to the
>implementations.

That sounds really good. It’s very important that both this and RFC7321
gets updated regularly.

> On the other hand there are lots of people still
>running IKEv1, so getting them to implementations might get time.

But IKEv1 is not in scope for RFC4307 or RFC4307bis so what they implement
or not should not be taken into consideration.


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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Dan Harkins]

On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote:
>
>> On 2 Nov 2015, at 11:44 AM, Paul Wouters  wrote:
>>
>> On Mon, 2 Nov 2015, Yoav Nir wrote:
>>
>>> P.S. Someone’s asked me off-list whether there is any IPsecME
>>> document that says not to trust SHA-1 in signatures, both AUTH payload
>>> and certificates, the way the TLS 1.3 document may end up saying for
>>> TLS. I’m wondering if RFC4307bis might be the place for this, in
>>> particular the signature in AUTH payload. Just something to think about
>>> before we bikeshed.RFC4307bis Bikeshedding Session.
>>
>> We should have text to clarify the difference of algorithm use in
>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH
>> processing crypto restrictions don't beling in 4307bis.
>
> I think we do need some kind of statement along the lines:
>  - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says
> “SHOULD use SHA-1” and this is a document from only last year…)
>  - Don’t use DSS because that is only defined with SHA-1.
>  - With ECDSA no need to specify because each curve comes with a hash

  Do you mean each _signature_ comes with a hash because you can
use different hash algorithms to sign with any given curve. X9.62 in
section 7.3, under Actions subsection e sub 1, even specifies what
to do if the hash function used in the signature produces a digest
that is greater than the length of the prime used in the curve
definition-- namely, take the left-most length of prime bits of the
digest to construct intermediate variable E.

  Dan.

>  - PSK is fine because you are using a PRF.
>  - With anything else, don’t use any hash weaker than SHA-256.
>
> If not here, where does this advice go?
>
> Yoav
>
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>


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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

[Yoav Nir]

> On 3 Nov 2015, at 9:42 AM, Tero Kivinen  wrote:
> 
> John Mattsson writes:
>> - BTW, What does it mean that an algorithm like ENCR_RC5 is not
>> listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”?
> 
> It means this document does not specify whether they should be used or
> not, i.e. MAY.

To elaborate a bit: there are a whole bunch of algorithms in each category, and 
we didn’t want to grab the entire table from IANA. 

The document lists the MUSTs and SHOULDs. That is the purpose of the document. 
Other algorithms are mentioned only if they’re ones that have previously been 
widely implemented and widely deployed, and that we believe it is time for them 
to no longer be so widely deployed. That is why DES, 3DES, MD5 and Group 2 get 
special mention. RC5 has never been very popular in IPSec, and the same can be 
said for Blowfish, Tiger, KPDK_MD5, and brainpoolP512r1. So we don’t mention 
those.

Yoav

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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

[Tero Kivinen]

Paul Wouters writes:
> > That sound reasonable, but shouldn’t the IoT devices have some guidelines
> > (maybe just a sentence) on what they should implement? We know that they
> > will not implement everything, and if they chose different subsets, they
> > will not be able to talk to each other.
> > 
> 
> I'd rather point to the minimal-IKE
> 
> https://tools.ietf.org/html/draft-kivinen-ipsecme-ikev2-minimal-00

Minimal IKEv2 cannot modify the mandatory to implement algorithms.
LWIG charter says that:

The group shall focus only on techniques that have been used
in actual implementations and do not impact interoperability
with other devices. The techniques shall also not affect
conformance to the relevant specifications.

I.e. the minimal IKEv2 should still be interoperable with any IKEv2
client. We had this discussion there when we said that even when
certificates are mandatory to implement in IKEv2, they are not
mandatory to use, i.e. you can also use shared key authentication
(which is also mandatory to implement).

The minimal IKEv2 cannot say that implementations should use some
specific algorithm unless that is mandatory to implement, as otherwise
it would not be interoperable to existing IKEv2 implementations
implementing only mandatory to implement algorithms.

Thats why minimal IKEv2 will not say anything about the algorithms, as
that would not be in charter with LWIG WG.

Here in the IPsecME WG, we can do that, i.e. I think adding separate
section for constrained devices, and list what algorithms they should
implement is good idea. 
-- 
kivi...@iki.fi

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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Tero Kivinen]

Yoav Nir writes:
> There is 1 for “RSA Digital Signature” and you can encode any hash
> function the you would like, but for ECDSA there is: 
> 9 - ECDSA with SHA-256 on the P-256 curve
> 10 - ECDSA with SHA-384 on the P-384 curve
> 11 - ECDSA with SHA-512 on the P-521 curve

Also number 3 DSS Digital Signature uses a SHA-1 hash

> So unless you go by RFC 7427, you can’t mix and match.

So everybody should move to use that :-)
-- 
kivi...@iki.fi

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

Re: [IPsec] Bikeshedding the RFC 4307bis Algorithms - side meeting

[Yoav Nir]

> On 3 Nov 2015, at 10:48 AM, Dan Harkins  wrote:
> 
> 
> 
> On Sun, November 1, 2015 7:21 pm, Yoav Nir wrote:
>> 
>>> On 2 Nov 2015, at 11:44 AM, Paul Wouters  wrote:
>>> 
>>> On Mon, 2 Nov 2015, Yoav Nir wrote:
>>> 
 P.S. Someone’s asked me off-list whether there is any IPsecME
 document that says not to trust SHA-1 in signatures, both AUTH payload
 and certificates, the way the TLS 1.3 document may end up saying for
 TLS. I’m wondering if RFC4307bis might be the place for this, in
 particular the signature in AUTH payload. Just something to think about
 before we bikeshed.RFC4307bis Bikeshedding Session.
>>> 
>>> We should have text to clarify the difference of algorithm use in
>>> IKE/IPsec and in AUTH processing. Initial thought is that AUTH
>>> processing crypto restrictions don't beling in 4307bis.
>> 
>> I think we do need some kind of statement along the lines:
>> - With RSA signatures, use SHA-256 or better, not SHA-1 (BTW: 7296 says
>> “SHOULD use SHA-1” and this is a document from only last year…)
>> - Don’t use DSS because that is only defined with SHA-1.
>> - With ECDSA no need to specify because each curve comes with a hash
> 
>  Do you mean each _signature_ comes with a hash because you can
> use different hash algorithms to sign with any given curve. X9.62 in
> section 7.3, under Actions subsection e sub 1, even specifies what
> to do if the hash function used in the signature produces a digest
> that is greater than the length of the prime used in the curve
> definition-- namely, take the left-most length of prime bits of the
> digest to construct intermediate variable E.

X9.62 allows it, but IKEv2 does not.  See the IKEv2 Authentication Method table 
at 
http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-12

There is 1 for “RSA Digital Signature” and you can encode any hash function the 
you would like, but for ECDSA there is:
9 - ECDSA with SHA-256 on the P-256 curve
10 - ECDSA with SHA-384 on the P-384 curve
11 - ECDSA with SHA-512 on the P-521 curve

So unless you go by RFC 7427, you can’t mix and match.

Yoav


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

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-00.txt

[Paul Wouters]

But we should explain that in the introduction :)

Sent from my iPhone

> On Nov 3, 2015, at 10:57, Yoav Nir  wrote:
> 
> 
>> On 3 Nov 2015, at 9:42 AM, Tero Kivinen  wrote:
>> 
>> John Mattsson writes:
>>> - BTW, What does it mean that an algorithm like ENCR_RC5 is not
>>> listed, does that mean “MAY”, “MUST NOT”, or “totally unspecified”?
>> 
>> It means this document does not specify whether they should be used or
>> not, i.e. MAY.
> 
> To elaborate a bit: there are a whole bunch of algorithms in each category, 
> and we didn’t want to grab the entire table from IANA. 
> 
> The document lists the MUSTs and SHOULDs. That is the purpose of the 
> document. Other algorithms are mentioned only if they’re ones that have 
> previously been widely implemented and widely deployed, and that we believe 
> it is time for them to no longer be so widely deployed. That is why DES, 
> 3DES, MD5 and Group 2 get special mention. RC5 has never been very popular in 
> IPSec, and the same can be said for Blowfish, Tiger, KPDK_MD5, and 
> brainpoolP512r1. So we don’t mention those.
> 
> Yoav
> 
> ___
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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