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

From: Thierry Moreau <[email-masked]>
Date: Wed, 29 Oct 2008 14:45:58 -0500

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: [email-masked]

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

---

From: <[email-masked]>
Date: Fri, 31 Oct 2008 14:37:46 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Thierry Moreau
> Sent: 29 October, 2008 21:46
> To: [email-masked]
> Subject: Re: [Sip] Last Call: 
> draft-ietf-sip-dtls-srtp-framework (Frameworkfor Establishing 
> an SRTP Security Context using DTLS) to ProposedStandard
> 
> 
> 
> The IESG wrote: