Subject: Re: [stir] Choice of STIR signature algorithm

From: Eric Burger <[email-masked]>
Date: Fri, 6 May 2016 10:18:27 -0400

FINALLY, a cogent *engineering* reason for needing RSA.

How about:
	MUST support ECDSA
	SHOULD support RSA unless you know you will not need it

Rationale:
ECDSA is ubiquitous today. ECDSA has lots of deployment advantages. Pretty much everything else s*cks in comparison.

However, especially for delegated certificates, there is a chance that one of the intermediate certificates will not be signed with ECDSA but with RSA. As such, if you know you will be deployed in such an environment, RSA is OK.

I would also suggest putting in a toxic waste warning in the document that the support of RSA is *not* a built-in downgrade attack. This is something that is covered by policy, not necessarily engineering. As such, a note to the implementor suggesting that if they know they should only see ECDSA (or better) signatures, they can feel free to reject an INVITE signed with RSA, even if it looks legitimate.

> On Apr 12, 2016, at 4:57 PM, Russ Housley <[email-masked]> wrote:
> 
> 
>> I don’t know why so much of the discussion during the Tuesday meeting was
>> about root certificates. As Eric pointed out on the mail, it is not hard
>> to get a ECDSA certificate as Digicert, Entrust, Globalising, Symantec,
>> Certicom, Comodo, and soon Let’s encrypt will happily give you one. As
>> Russ pointed out most (or all) of these ECDSA certificates will be signed
>> by a RSA root certificate. But root certificates and verification of the
>> credentials seems to be out of scope of STIR and does not affect the
>> PASSporT object. As far as I understand, the only thing STIR should
>> specify is verification of the PASSporT object.
> 
> We will need to say that the validation will include RFC 5280 path validation to a trust anchor.  This means that the signature on each certificate will be validated.  So, for quite some time we will need to be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT object or on a certificate, even if we state a strong preference for ECDSA.
> 
> Russ
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: Russ Housley <[email-masked]>
Date: Mon, 9 May 2016 16:37:13 -0400

I would rather be a bit more granular.

	MUST support ECDSA for PASSporT signatures
	SHOULD support RSA PKCS#1 v1.5 for PASSporT signatures

and

	MUST support ECDSA for certificate signatures
	MUST support RSA PKCS#1 v1.5 for certificate signatures

Then, we should say something to product planners that at some point in the future, we expect support for RSA to be downgraded.

Russ

---

From: Eric Burger <[email-masked]>
Date: Mon, 9 May 2016 17:31:03 -0400

Sounds good.

> On May 9, 2016, at 4:37 PM, Russ Housley <[email-masked]> wrote:
>

---

From: Chris Wendt <[email-masked]>
Date: Tue, 10 May 2016 11:23:09 -0400

+1

> On May 9, 2016, at 5:31 PM, Eric Burger <[email-masked]> wrote:
> 
> Sounds good.
>

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 9 May 2016 18:25:35 +0000

Russ's assertion that "for quite some time we will need to be able to
validate RSA PKCS#1 v1.5 signatures" would lead me to think RSA should
remain a MUST.

As I said in Buenos Aires, I am deferring to Russ, and Sean, and EKR, and
the other people who live and breathe this world to provide us guidance. I
asked Sean to write the text for this.

Jon Peterson
Neustar, Inc.

On 5/6/16, 7:18 AM, "stir on behalf of Eric Burger" <[email-masked]
on behalf of [email-masked]> wrote:

>ECDSA is ubiquitous today. ECDSA has lots of deployment advantages.
>Pretty much everything else s*cks in comparison.
>
>However, especially for delegated certificates, there is a chance that
>one of the intermediate certificates will not be signed with ECDSA but
>with RSA. As such, if you know you will be deployed in such an
>environment, RSA is OK.
>
>I would also suggest putting in a toxic waste warning in the document
>that the support of RSA is *not* a built-in downgrade attack. This is
>something that is covered by policy, not necessarily engineering. As
>such, a note to the implementor suggesting that if they know they should
>only see ECDSA (or better) signatures, they can feel free to reject an
>INVITE signed with RSA, even if it looks legitimate.
>
>>> I don¹t know why so much of the discussion during the Tuesday meeting
>>>was
>>> Certicom, Comodo, and soon Let¹s encrypt will happily give you one. As
>> We will need to say that the validation will include RFC 5280 path
>>validation to a trust anchor.  This means that the signature on each
>>certificate will be validated.  So, for quite some time we will need to
>>be able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT
>>object or on a certificate, even if we state a strong preference for
>>ECDSA.
>> 
>> Russ
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 May 2016 08:36:58 -0700

This seems largely reasonable. I would consider removing the SHOULD for RSA
for
PASSporT signatures, for two reasons:

1. There's no legacy to deal with
2. Because these objects are just sent out with no negotiation, it's not
that useful
to know that relying parties might or might not support your algorithm. The
safe
thing to do would be ECDSA.

I would also note that the above doesn't specify a curve, but I assume
we're talking
P-256.

-Ekr

On Mon, May 9, 2016 at 1:37 PM, Russ Housley <[email-masked]> wrote:

> Then, we should say something to product planners that at some point in
> the future, we expect support for RSA to be downgraded.
>
> Russ
>
>
> one of the intermediate certificates will not be signed with ECDSA but with
> RSA. As such, if you know you will be deployed in such an environment, RSA
> is OK.
> >
> something that is covered by policy, not necessarily engineering. As such,
> a note to the implementor suggesting that if they know they should only see
> ECDSA (or better) signatures, they can feel free to reject an INVITE signed
> with RSA, even if it looks legitimate.
> >
> certificate will be validated.  So, for quite some time we will need to be
> able to validate RSA PKCS#1 v1.5 signatures, either on the PASSporT object
> or on a certificate, even if we state a strong preference for ECDSA.
> >>
> >> Russ
> >>

---

From: Russ Housley <[email-masked]>
Date: Mon, 16 May 2016 17:01:51 -0400

Eric:

I was thinking P-256, but I could be talked into:

	MUST support P-256
	SHOULD support P-384

Russ

On May 15, 2016, at 11:36 AM, Eric Rescorla <[email-masked]> wrote:

> This seems largely reasonable. I would consider removing the SHOULD for RSA for
> 2. Because these objects are just sent out with no negotiation, it's not that useful
> to know that relying parties might or might not support your algorithm. The safe
> I would also note that the above doesn't specify a curve, but I assume we're talking
> P-256.
> 
> -Ekr
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 16 May 2016 23:30:54 -0400

> I was thinking P-256, but I could be talked into:

I would tend to just think MUST p-256. Less is more

-Ekr

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Tue, 17 May 2016 03:50:59 +0000

Eric

Why less is more?

If we are not forward thinking (directionally), it will make it harder to take the next step

Thanks

Martin C Dolly
Lead Member of Technical Staff
Core & Government/Regulatory Standards
AT&T
Cell: 609-903-3360
Email: [email-masked]<mailto:[email-masked]>

On May 16, 2016, at 11:31 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, May 16, 2016 at 5:01 PM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
Eric:

MUST support P-256
SHOULD support P-384

-Ekr

Russ

On May 15, 2016, at 11:36 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

On Mon, May 9, 2016 at 1:37 PM, Russ Housley <[email-masked]<mailto:[email-masked]>> wrote:
I would rather be a bit more granular.

and

Russ

_______________________________________________
stir mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/stir

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 May 2016 14:58:46 -0700

Why would P-384 be a logical next step?

On Mon, May 16, 2016 at 8:50 PM, DOLLY, MARTIN C <[email-masked]> wrote:

> Email: [email-masked]
> On May 16, 2016, at 11:31 PM, Eric Rescorla <[email-masked]> wrote:
>
>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 19 May 2016 08:09:08 -0400

>> I would also note that the above doesn't specify a curve, but I assume we're talking

Yes:

https://tools.ietf.org/html/rfc7518#section-3.1 <https://tools.ietf.org/html/rfc7518#section-3.1>

---

From: Chris Wendt <[email-masked]>
Date: Thu, 19 May 2016 08:11:54 -0400

Whenever we say SHOULD i believe this is in the context of the authentication service only, because this would imply a MUST on the verification side, right?

So, should we go there or just stick with MUST on

> On May 16, 2016, at 11:30 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Mon, May 16, 2016 at 5:01 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
> Eric:
> 
> On May 15, 2016, at 11:36 AM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On Mon, May 9, 2016 at 1:37 PM, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:

---

From: Eric Burger <[email-masked]>
Date: Wed, 25 May 2016 13:29:23 -0400

And Eric’s [B’s] Law™ holds: Every SHOULD MUST have an UNLESS. Otherwise, the SHOULD is really a MAY which is really useless in a protocol specification.

> On May 19, 2016, at 8:11 AM, Chris Wendt <[email-masked]> wrote:
> 
>> On May 16, 2016, at 11:30 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> [email-masked] <mailto:[email-masked]>

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 May 2016 15:41:18 -0400

This is what I am hearing…

        MUST support ECDSA with P-256 for PASSporT signatures

and

        MUST support ECDSA with P-256 for certificate signatures
        MUST support RSA PKCS#1 v1.5 for certificate signatures

Russ