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. 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. (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.) Best regards, Pasi > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of ext Thierry Moreau > Sent: 29 October, 2008 21:46 > To: ietf@xxxxxxxx > Subject: Re: [Sip] Last Call: > draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing > an SRTP Security Context using DTLS) to ProposedStandard > > > > The IESG wrote: > > The IESG has received a request from the Session Initiation > Protocol WG > > (sip) to consider the following document: > > > > - 'Framework for Establishing an SRTP Security Context using DTLS ' > > <draft-ietf-sip-dtls-srtp-framework-04.txt> as a > Proposed Standard > > > > This document approval at the IESG level might signal a shift in the > IETF consistent use of PKI security certificates for remote party > authentication in (D)TLS protocols. > > The present comment is submitted to make sure that the IESG > decision is > an educated one, and not made inedvertantly. If another document > previously approved by the IESG is an accepted precedent for > the subject > matter discussed below, the present comment may be ignored. > > The present comment is neither for or against advancement of > the draft. > > From the introduction section of the draft: > > "The goal of this work is to provide a key negotiation technique that > allows encrypted communication between devices with no prior > relationships." > > "The media is transported over a mutually authenticated DTLS session > where both sides have certificates. It is very important to > note that > certificates are being used purely as a carrier for the > public keys of > the peers. This is required because DTLS does not have a mode for > carrying bare keys, but it is purely an issue of formatting. The > certificates can be self-signed and completely self-generated." > > From these indications it is easy to see that the framework would > (ideally) require a (D)TLS protocol derivative in which "bare" peer > public keys can be carried without the burden of security > certificate. > Despite the above wording, the current lack of such a (D)TLS > mode might > be more than a mere "issue of formatting" - it might be a > consequence of > a long-standing policy at the IETF. > > If this draft is approved by the IESG, it might signal that > similar uses > of self-signed-at-will (or otherwise meaningless) security > certificates > is an approved approach for circumventing the lack of a "bare public > key" (D)TLS mode. Note that this is different from the PSK-TLS mode > (pre-shared key) which explicitly relies on pre-established symmetric > keys as a *replacement* for security certificate assurance. > > It is my understanding that the self-signed-at-will (or otherwise > meaningless) certificate approach is technically feasible but should > remain standardized outside of the IETF activities, if at > all. Based on > this understanding, my draft draft-moreau-pkix-aixcm (that > also falls in > this broad approach) has been submitted as a non-IETF > informational RFC. > (A comparative analysis between the SIP draft and mine is a matter of > implementation strategy for the overall approach, and is thus out of > scope for the present comment.) > See http://www.rfc-editor.org/queue2.html#draft-moreau-pkix-aixcm . > > In any event, this comment is made for the sole purpose of making > IESG/IETF directions more explicit. > > Thanks to Eric Rescorla who brought my attention to the similarities > between the SIP draft and an early version of the ideas > behind my draft. > > Regards, > > > -- > > - 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: thierry.moreau@xxxxxxxxxxxxx > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf