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

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 10:28:08 +0900

Hi, all

Since we’ve had quite a bit of bikeshedding about this on the list, we’d like to gather and has it out face to face.

So this Wednesday at 7:00 PM, right after the plenaries, we’ll meet at room 421 to hash this out.

Everyone’s invited, obviously.

Yoav

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.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Nov 2015 21:44:48 -0500 (EST)

> 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…

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.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 12:21:57 +0900

> On 2 Nov 2015, at 11:44 AM, Paul Wouters <[email-masked]> wrote:
> 

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
 - 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

---

From: Paul Wouters <[email-masked]>
Date: Sun, 1 Nov 2015 22:27:40 -0500 (EST)

> 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?

Paul

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 12:38:11 +0900

> On 2 Nov 2015, at 12:27 PM, Paul Wouters <[email-masked]> wrote:
> 

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. 

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.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 12:44:22 +0900

Forgot the link…

> On 2 Nov 2015, at 12:38 PM, Yoav Nir <[email-masked]> wrote:
> 
> 

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

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 2 Nov 2015 11:32:40 +0200

>> 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 anoth…

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

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 18:42:50 +0900

> On 2 Nov 2015, at 6:32 PM, Yaron Sheffer <[email-masked]> wrote:
> 
> 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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 2 Nov 2015 17:48:26 -0800 (PST)

On Sun, November 1, 2015 7:21 pm, 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.
>>
>  - 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…)

  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.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Nov 2015 11:04:04 +0900

> On 3 Nov 2015, at 10:48 AM, Dan Harkins <[email-masked]> wrote:
> 
> 
> 
>>>> P.S. Someoneâs asked me off-list whether there is any IPsecME
>>>> TLS. Iâm wondering if RFC4307bis might be the place for this, in
>> â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.

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

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 3 Nov 2015 06:33:58 +0200

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: 

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 :-)
-- 
[email-masked]

---

From: Yoav Nir <[email-masked]>
Date: Tue, 3 Nov 2015 13:58:50 +0900

> On 3 Nov 2015, at 1:33 PM, Tero Kivinen <[email-masked]> wrote:
> 
> Yoav Nir writes:

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

---

From: "Dan Harkins" <[email-masked]>
Date: Mon, 2 Nov 2015 21:37:51 -0800 (PST)

>> 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.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Nov 2015 13:34:50 +0900

Reminder. It’s tonight at 7:00 PM Japan time, 10:00 UTC.

We won’t have Meetecho or audio streaming, but if a few remote people want to participate, we might be able to do something with Skype.

Yoav

> On 2 Nov 2015, at 10:28 AM, Yoav Nir <[email-masked]> wrote:
> 
> Hi, all
> 
> <RFC4307_Bikeshedding_Session.ics>