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.
Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf