Subject: [Sip] DTLS Certificate Request vs Self-signed EE Certificates vs R-EXISTING

From: Thierry Moreau <[email-masked]>
Date: Fri, 25 Jul 2008 09:56:53 -0500

Dears SIP wg participants,

You may be surprised that I come to comment the 
draft-ietf-sip-dtls-srtp-framework-02 at this point in time - I am also!

Anyway, my comment is about DTLS protocol compliance and the use of 
self-signed certificates. Maybe there are things I don't see, but I 
wonder if the envisioned use of self-signed certificates is compliant 
with DTLS, even assuming the "legitimacy" of accepting self-signed 
certificates without a strong trust base in the PKI spirit.

Here are the technical details. I assume the DTLS server protocol entity 
"S" wishes to accept either "self-signed" EE certificates or 
certificates issued by a couple of trusted CA (requirement R-EXISTING). 
"S" would send a DTLS certificate request message containing either an 
empty list of CA distinguished names (meaning "I accept any CA") of a 
list of CA distinguished name (meaning "I trust these CAs"). In the 
latter case, the DTLS client protocol entity "C" would not be allowed to 
send a self-signed EE certificate. In the former case, "C" would be 
allowed to send any certificate it has on hand, including a self-signed 
EE certificate.

There are two alternate adjustments to the draft I see that would 
improve its technical quality if the above paragraph is correct:

A)	State explicitly that the empty list of CA distinguished names (in 
DTLS certificate request messages) option applies. It is then preferable 
to describe the self-signed EE certificate as a special case of e.g. 
"any X.509 security certificate holding a public key that the end entity 
controls (of which the end entity controls the private key counterpart)".

B)	Specify a public domain private key value (i.e. breached, snake-oil, 
meaningless ...) and a dummy CA distinguished name for the corresponding 
public key and let the EE auto-issue an X.509 certificate under this CA 
as a replacement of certificate self-signature.

The idea for option B) was recently submitted to the PKIX wg (see 
http://www.imc.org/ietf-pkix/mail-archive/msg04498.html) and its 
relevance to the draft-ietf-sip-dtls-srtp-framework (and to 
draft-ietf-avt-dtls-srtp as well) was raised by one of its authors.

Hope it helps,

-- 

- Thierry Moreau

CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, Qc
Canada   H2M 2A1

Tel.: (514)385-5691
Fax:  (514)385-5900

web site: http://www.connotech.com
e-mail: [email-masked]

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 08:08:40 -0700

At Fri, 25 Jul 2008 09:56:53 -0500,
> certificates without a strong trust base in the PKI spirit.

It's explicitly compliant with DTLS. Here's what RFC 4346 says about
certificates (S 1)

   the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

> allowed to send any certificate it has on hand, including a self-signed 

Yes, both of these are legal in this instance. The basic setting
is one in which any certificate is accepted, but implementations
could of course be configured to require 3rd party certificates.

> controls (of which the end entity controls the private key counterpart)".

I don't have a problem with indicating that the server should 
provide a compatible CertificateRequest message, but honestly
I think this is redundant, since DTLS/TLS specify how to construct
the CertificateREquest.

> as a replacement of certificate self-signature.

I don't think this is that great an idea. The semantics of self-signed
certs are commonly understood and I don't think this adds much
value.

-Ekr

---

From: Thierry Moreau <[email-masked]>
Date: Fri, 25 Jul 2008 11:13:22 -0500

> I think this is redundant, since DTLS/TLS specify how to construct

It's not the server behavior that would benefit from a document 
clarification, it's the client's behavior. If the CertificateRequest 
message contains an empty list of distinguished names, it is valid for 
the client entity to send EITHER 1) a self-signed security certificate 
or 2) any certificate holding a public key it controls. The document 
ambiguity, as it stands, is whether 2) is allowed in the two drafts as 
it is in the bare DTLS.

> certs are commonly understood and I don't think this adds much

It would allow a server to announce its preferred trusted CAs 
(fulfilling R-EXISTING) *AND* its willingness to accept "auto-issued" 
certificates. An EE having (genuine) certificates from CA-1 and CA-2 
would select among these two per server expressed preferences. I guess 
you see the point.

But admittedly, I can't speak much for the SIP application area.

Regards,

-- 

- Thierry Moreau

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 Jul 2008 09:23:10 -0700

At Fri, 25 Jul 2008 11:13:22 -0500,
> ambiguity, as it stands, is whether 2) is allowed in the two drafts as 

I don't think it's ambigous, but I'll try to add some clarifying
text.

> would select among these two per server expressed preferences. I guess 

Yes, this seems to me to be of relatively modest value. In any
case, this is a feature which could easily be added at some point
in the future if such a fake CA ever existed.

-Ekr

---

From: Thierry Moreau <[email-masked]>
Date: Sun, 27 Jul 2008 11:44:28 -0500

Dear Eric, SIP participants:

	I don't want to argue on the overall question of EE self-signed 
certificates for SIP security requirements. However, some basic facts 
should be noted, if only for the record.

	The basic TLS handshake has some "features" which are noteworthy in the 
present context:

1)	The TLS protocol provides no direct support for EE public keys that 
are not conveyed in X.509 security certificates.

2)	The TLS protocol Certificate Request message does not allow a server 
to announce its willingness to accept at once EE self-signed 
certificates and a list of trusted CA names.

3)	This leaves a server operator wishing to support EE self-signed 
certificates *and* a list of trusted CA names with the following dilemma:

	a)	it announces its list of trusted CAs in the Certificate Request 
message and fails to support the EE self-signed certificate mechanism, or

	b)	it announces its willingness to accept any CA in EE certificates 
returned by clients, and then will experience EEs returning 
certificates issued by untrusted CAs.

	Obviously, this is a property of the TLS protocol not specific to SIP. 
Point 1) is the basic issue. Point 2) arises when the EE self-signed 
certificate mechanism is introduced as a hack for point 1). Point 3) is 
a side-effect of this hack.

	The SIP security framework requires a solution to 1). This requirement 
is parhaps not unique. The selection of the EE self-signed certificate 
hack should be done under full disclosure of the above, plus the 
availability of another hack contributed at the start of this thread.

Regards,

-- 

- Thierry Moreau