Subject: [TLS] Re: comedia-tls: proposed change for certificate identities

From: Sam Hartman <[email-masked]>
Date: Sun, 29 Jan 2006 15:19:37 -0500

>>>>> "Jonathan" == Jonathan Lennox <[email-masked]> writes:

    Jonathan> * If your SDP was sent over an end-to-end authenticated
    Jonathan> and integrity-protected channel, there are no
    Jonathan> constraints on what identity you assert in your TLS
    Jonathan> certificates; you can use anything you want.  Identity
    Jonathan> is handled by the transporting protocol.

What about hop-by-hop authenticated with each hop integrity protected.
IMHO in many environments, this presents acceptable man-in-the-middle
risk.  I think that it may present significantly easier to deal with
usability issues so I think it should at least be allowed if not
encouraged.

    Jonathan> * If it wasn't, however, you have to have use
    Jonathan> certificate that asserts either a) the host in your SDP
    Jonathan> c= line (which can be either an IP address or host
    Jonathan> name), or b) a URI representing the protocol
    Jonathan> transporting the SDP (which in practice usually means a
    Jonathan> SIP URI).

    Jonathan> * For self-signed certificates sent un-authenticated,
    Jonathan> you can use SSH "leap-of-faith" mode: you warn the user
    Jonathan> if you've never seen a certificate before for a given
    Jonathan> identity, or if the certificate you got for an identity
    Jonathan> is different from the one you have cached.  This means
    Jonathan> that once you've communicated with someone, you can be
    Jonathan> sure no one's launching a man-in-the-middle on you in
    Jonathan> the future.  It does, however, present usability
    Jonathan> problems when someone has to change their cert.

Do you have explicit language that a self-signed cert cache must not
get in the way of the rekeying in the previous two cases?
    Jonathan> The other question is whether it's worthwhile to say
    Jonathan> that single-hop sips connections should count as
    Jonathan> end-to-end integrity-protected.  On the one hand, they
    Jonathan> are; on the other hand, allowing certain operational
    Jonathan> modes for single-hop but not multi-hop SIP seems like a
    Jonathan> bad idea, and it would break in the face of third-party
    Jonathan> call control and other back-to-back UAs.

    Jonathan> Do people have alternate suggestions, or thoughts on
    Jonathan> better solutions?  I note that these requirements are
    Jonathan> strictly more lenient than the protocol mode which got
    Jonathan> through WGLC.

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Sam Hartman <[email-masked]>
Date: Mon, 30 Jan 2006 15:50:36 -0500

>>  Do you have explicit language that a self-signed cert cache
    >> must not get in the way of the rekeying in the previous two
    >> cases?

    Jonathan> I'm not sure how I distinguish rekeying from a
    Jonathan> man-in-the-middle attacker presenting a new certificate.
    Jonathan> Is there an obvious distinction here?  Does it have to
    Jonathan> do with certificate expiration?

Basically,  what I never want to happen is:

* you get a self signed cert in a previous session

* In the current session you have end-to-end integrity and get
  errors/warnings because you are not getting the same cert you did in
  that previous session.