Subject: [IPsec] Take a stand for key hygine

From: Watson Ladd <[email-masked]>
Date: Thu, 17 Nov 2016 16:18:41 -0800

Dear all,

In reviewing the proceedings now online I noticed that someone is
proposing to support using the same key with multiple signature
algorithms. This is a bad idea that makes everyone sad. Showing that a
signature under one algorithm cannot be abused to obtain another
signature with a different algorithm is not something that is done.

Sincerely,
Watson Ladd

---

From: Yoav Nir <[email-masked]>
Date: Fri, 18 Nov 2016 11:31:37 +0900

Hi, Watson

> signature with a different algorithm is not something that is done.

I don’t know where you got that, but I haven’t reviewed the proceedings. I believe you mean what I said about contexts in Ed448 (and possibly Ed25519ctx) from the CFRG draft.

The question raised in IPsec (and TLS and in 30 minutes also in Curdle) was whether to specify a non-empty context string fro Ed448 (like “IKEv2”), or whether to just use the empty string. 

The argument for adding the string is that people use the same keys for different purposes (not different algorithms) anyway, even if we tell them not to, and by adding a context string we’re preventing signing oracles between IKEv2 and other protocols. 

The argument against is that this encourages the bad practice of using the same key for different purposes. We could end up with people regularly re-using keys and then they do it with RSA. Or EDCSA. Or any algorithm that does not feature contexts.

At no point did anyone propose support for the same key with multiple signature algorithms or even for multiple purposes.

HTH

Yoav

---

From: Valery Smyslov <[email-masked]>
Date: Fri, 18 Nov 2016 12:03:05 +0900

Hi Watson,

I also wonder where did you come to such a conclusion from.

Besides discussion about contexts in EdDSA, there was a slide
in my presentation that was about signature formats ambiguity
in IKEv2, that may be interpreted as a promotion for using the same
key with different signature algorithms. This interpretation is wrong,
the purpose of the slide was to show, that the same, say RSA key can
be used either in RSASSA-PKCS1 scheme, or in RSASSA-PSS scheme
and there are some interoperability issues with that in IKEv2. 
By no means this slide meant that the key is used in both schemes.

Regards,
Valery Smyslov. 

From: Yoav Nir
Sent: 18 ноября 2016 г. 11:31
To: Watson Ladd
Cc: [email-masked] WG
Subject: Re: [IPsec] Take a stand for key hygine

Hi, Watson

HTH

Yoav

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

---

From: Watson Ladd <[email-masked]>
Date: Thu, 17 Nov 2016 19:05:51 -0800

> At no point did anyone propose support for the same key with multiple signature algorithms or even for multiple purposes.

I might be confused, but the slides in
https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf
seem to very clearly want something else. Apologies for my
insufficient context inclusion.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Tero Kivinen <[email-masked]>
Date: Fri, 18 Nov 2016 05:38:11 +0200

> insufficient context inclusion.

Yes, with RSA I think it might be quite common for people to use same
key for both RSA PKCS#1 v1.5 and RSA-PSS, and there is not really
anything we can do for that.

On the other hand the interoperability issue we have now does not
really care whether you have one or two RSA private keys, as long as
initiator can use either RSA-PSS or RSA PKCS#1 v1.5, and do not know
which one responder will accept.

I think we might want to add text in the rfc4307bis saying that same
key should not be used with both RSA-PSS and PKCS#1 v1.5.

The rfc4307bis will be in IETF Last Call soon, so if you can read that
and see what it says about the signature algorithms and see if there
is something we need to add there, that would be great.
-- 
[email-masked]

---

From: Watson Ladd <[email-masked]>
Date: Thu, 17 Nov 2016 20:01:27 -0800

> which one responder will accept.

What about the approach of treating these as different authentication
methods? Or am I misunderstanding the scope of the problem? I'm not
that familiar with IKE2.

> is something we need to add there, that would be great.

I will look over it.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2016 00:21:24 +0200

> On 18 Nov 2016, at 5:38, Tero Kivinen <[email-masked]> wrote:
> 
> Watson Ladd writes:

If that is a problem, then it is more serious for TLS. TLS 1.2 has only PKCS#1. TLS 1.3 has only PSS.  So a server that uses a single certificate with RSA for both versions (probably most servers in 1-2 years) will be producing both kinds of signatures from the same key.

If that’s a problem, it should be raised during WGLC of TLS 1.3 (which si now)

Yoav

---

From: Valery Smyslov <[email-masked]>
Date: Sat, 19 Nov 2016 08:38:34 +0900

Hi Yoav,

or the servers must be provided with two certificates – one for TLS 1.2
and the other for TLS 1.3, that won’t make server owners happy.

I think it is a good idea to raise this issue in TLS WG.

Regards,
Valery.

From: Yoav Nir
Sent: 19 ноября 2016 г. 7:21
To: Tero Kivinen
Cc: [email-masked] WG; Watson Ladd
Subject: Re: [IPsec] Take a stand for key hygine

Yoav

---

From: Valery Smyslov <[email-masked]>
Date: Sat, 19 Nov 2016 08:34:20 +0900

Hi Watson,

the problem is not that the host cannot deduce from received AUTH payload
what kind of signature was used – the AUTH payload includes AlgorithmIdentifier,
so these signatures are treated differently. The problem is that host cannot
guess what kind of signatures the peer supports, that can lead to SA setup failure.
This is not a cryptographic problem, this is IKEv2 protocol problem.

And it was probably not very precise text in my presentation – 
it meant that we have a problem if the same kind of key (say RSA)
can be used with different signature schemes (say RSA-PKCS and RSA-PSS),
not necessary the same key.

Regards,
Valery.

From: Watson Ladd
Sent: 18 ноября 2016 г. 13:01
To: Tero Kivinen
Cc: [email-masked] WG; Yoav Nir
Subject: Re: [IPsec] Take a stand for key hygine

I will look over it.

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2016 10:32:31 +0200

Definitely won’t, but I first want to know if this is actually a problem.

I’ll ask on the CFRG list.

Yoav

> On 19 Nov 2016, at 1:38, Valery Smyslov <[email-masked]> wrote:
> 
> Hi Yoav,
>  
> From: Yoav Nir <mailto:[email-masked]>
> To: Tero Kivinen <mailto:[email-masked]>
> Cc: [email-masked] WG <mailto:[email-masked]>; Watson Ladd <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/ipsec <https://www.ietf.org/mailman/listinfo/ipsec>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Nov 2016 02:39:24 -0500 (EST)

> methods? Or am I misunderstanding the scope of the problem? I'm not

The AUTH signature include data that is unique to each connection. For
IKEv2, both sides generate a randomized SPI number that is included in
the data to sign as well as a nonce. So an attacker would have to trick
an endpoint in using one RSA version and then resend the IKE_AUTH packet
to try and do the other RSA version. It's not allowed by protocol AFAIK.

https://tools.ietf.org/html/rfc7296#section-2.15

So I don't think it is a concern, but I think we should indeed look at
TLS as well, and agree on whether or not to use a context.

Paul