Subject: Re: [Sip] Last Call: draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing an SRTP Security Context using DTLS) to ProposedStandard

From: Thierry Moreau <[email-masked]>
Date: Mon, 03 Nov 2008 11:30:24 -0500

Dear Pasi,

Thanks for pointing many RFCs and an approved draft as useful precedents 
applicable to the draft-ietf-sip-dtls-srtp-framework. This indeed 
addresses the issue I raised.

See in-line below for feedback not specific to the draft at stake.

[email-masked] wrote:
> Hi Thierry,
> 
> There's ample precedent for using self-signed certificates to carry
> public keys in situations where a "bare public key mode" (if TLS/DTLS
> had it -- IKEv2 does have this, BTW) would have worked, too.
> 
> Exactly the same approach as in this draft (exchange fingerprints via
> SDP, and use those to check self-signed certificates used in TLS/DTLS)
> is already used in RFCs 4572, 4582, and 4975.
> 

In this lineage, I find it difficult to follow the many security schemes 
which ultimately allows a relying party to affix a trust rating to the 
bind between a public key and a remote party identification. (The many 
security schemes are created by the many alternatives in the 
specifications.) As an example, in the section 14.4 (end of 2nd 
paragraph) in RFC4975, I read:

   "If the endpoint is also able to make
    anonymous sessions, a distinct, unique certificate MUST be used for
    this purpose.  For a client that works with multiple users, each user
    SHOULD have its own certificate.  Because the generation of
    public/private key pairs is relatively expensive, endpoints are not
    required to generate certificates for each session."

It is unclear whether "distinct, unique certificate" also imply 
"dictinct, unique public/private key pair". I don't recall a generic 
mandatory provision where certificate rollover implies public key 
rollover. (Obviously public key commonality among users or sessions 
somehow impairs anonymity.)

This is just an example of questions I ask myself in reading these 
elaborate specifications where the rationales for establishing trust are 
found only after figuring out a specific selection of protocol 
deployment options.

> Several other RFCs (e.g. 3261, 3920, 5380) and drafts (e.g.
> draft-ietf-syslog-transport-tls, currently in RFC Editor Queue) 
> also use self-signed certificates in some way.
> 

I broadly classify these in two categories:

SSH-public-key-introduction derivatives, where an operator is expected 
to accept the remote party public key upon first use, which is an 
un-debatably effective deployment strategy.

RFC3920 (section 14.2) is an interesting case which formalizes the 
browser pop-up windows for accepting security certificate (otherwise 
thou shall not browse) in the case of instant messaging.

I wasn't able to come up with a characterization fo RFC5380. It seems to 
make a statement about the possible existence of self-signed 
certificates, but the purpose of this statement was unclear to me.

> (Of course, using self-signed certificates for some particular purpose
> can't set a precedent that they'd be the best solution to all possible
> problems. They're a useful tool, but some problems require using
> other tools.)
> 

(Indeed.)

> Best regards, 
> Pasi

Same,

-- 

- Thierry Moreau

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