Thanks Robert.
Exactly my toughts as well. I think it would mean that the draft should
include some language about prefereing TLS transport anyhow (it was my
intention to add that in).
> -----Original Message-----
> From: Robert Sparks [mailto:[EMAIL PROTECTED]
> Sent: Thursday, March 29, 2007 07:14
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] some comments on draft-ietf-sip-sips
>
> I also think disallowing upgrades is the better course.
>
> I still have misgivings about how likely an implementation is
> to do the "right thing" WRT informing its user when it
> receives an INVITE over TLS with a sips: RURI, but a sip: URI
> in the To: header. If it makes the mistake of presenting this
> as a "secure" invitation, the UAS's user may make a very
> wrong choice in answering the call (and possibly compound the
> error later with REFERs in that dialog).
>
> If we do allow an upgrade retarget, we are sanctioning a
> downgrade in the reverse direction for subsequent requests in
> the dialog that gets established. Thus the only "right thing"
> for the above implementation to do is to present this call as
> a normal sip: call.
>
> So the only benefit of allowing an upgrade I see is that some
> part of the signaling happens over TLS. But that can be
> achieved by preferring hop-by-hop TLS anyhow. In a flow
> through the networks we anticipate, retargetting anywhere but
> the (near) last hop will occur because of configuration,
> usually under the control of the operator of the retargetting element.
> That same level of configuration effort can go into properly
> populating DNS to cause TLS to be used. The retargetting due
> to registrations at the (near) last hop is likely to be
> mooted by outbound.
>
> It appears to greatly simplify things if this kind of upgrade
> can't happen and we rely on redirection all the way to the endpoint.
>
> RjS
>
> On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote:
>
> > In a separate thread, we've been discussing whether we can
> make this
> > draft normative and finally go about 'fixing' the things that make
> > SIPS broken. Besides the last hop exception problem, there
> is another
> > bit which is very problematic:
> >
> >> The presence of a SIPS Request-URI does not necessarily indicate
> >> that
> >> the request was sent securely on each hop. As described in
> >> [RFC3261]/26.4.4, a proxy may legitimately retarget a
> request from
> >> SIP to SIPS. Therefore, a UAS MUST NOT assume on the
> basis of the
> >> Request-URI alone that SIPS was used for the entire
> request path.
> >
> >
> > Retargeting from sips to sip is a lot like the last hop exception
> > rule, and it really ruins the ability for the UAS to verify
> the main
> > security property provided by SIPS. Instead of the ad-hoc
> algorithms
> > suggested as ways to actually verify this, can we change this rule?
> > Proxy MUST NOT retarget a sips URI to sip. I think I've
> suggested tihs
> > in the past that I think we need to outright forbid up and
> downgrades.
> >
> > Section 4.2 - does this evaporate if we can make this change to not
> > change sip to sips?
> >
> > Indeed I think this document becomes oodles simpler when we
> eliminate
> > these two exceptions. I think the doc is still pretty complicated
> > since there are so many exceptions and variations. I want it to be,
> > you ar eeither sips, in which case EVERYTHING is sips, or
> you are sip,
> > in which case NOTHING is sips. Really easy that way, and it
> gives us
> > the security property we need.
> >
> >> The USC registers either a SIPS or a SIP AOR. From a routing
> >> perspective, it does not matter which one is used for
> registration
> >> as
> >> they identify the same resource.
> >> If all the Contacts are SIPS, a SIPS AOR MUST also be
> used by the
> >> UAC. If at least one of the Contacts is SIP or is
> neither SIP nor
> >> SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST
> also be used
> >> by
> >> the UAC.
> >
> > isn't this a contradiction? The first paragraph says that
> it doesn't
> > matter whether you use sip or sips. Then the next says why
> you pick a
> > sip or sips aor.
> >
> > Also I tihnk the text should be restructured a bit to say
> that, a UA
> > can operate in one of three modes - sips only, sip only or
> either. And
> > then based on that, how do you set each of the parameters in the
> > REGISTER (To, from, contact, r-uri). The current text is
> inverted and
> > you have to work backwards in some places to sort it out.
> >
> > I don't really see why the AOR in the To is relevant at all
> (sip vs.
> > sips).
> >
> >> A registrar MUST only accept a binding to a SIPS Contact
> if all the
> >> appropriate URIs are of the SIPS scheme: i.e., the Request-URI,
> >> the
> >> AOR (i.e., To header), the From header, the Contacts
> and all the
> >> Path
> >> headers. If the URIs are not of the proper SIPS scheme, it must
> >> reject the REGISTER with a 403 "Forbidden".
> >
> > I don't see why the To and From are relevant. Indeed I think a sips
> > contact can be accepted as long as the r-uri was sips. For
> path, its
> > really a double check since they should have been sips
> based on other
> > rules, should probably make that clear.
> >
> >> SIPS in a Dialog
> >> There MUST be only one Contact in any request resulting in the
> >> establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).
> >
> > This is a basic 3261 requirement having nothing to do with
> sips; might
> > want to merely state this as fact.
> >
> >> As mandated by [RFC3261]/8.1.1.8, in a request, if the
> Request-URI or
> >> top Route header field value contains a SIPS URI, the Contact
> >> header
> >> field MUST contain a SIPS URI as well. Furthermore, as
> mandated
> >> by
> >> [RFC3261]/12.1.1, if the request that initiated the dialog
> >> contained
> >> a SIPS URI in the Request-URI or in the top Record-Route header
> >> field
> >> value, if there was any, or the Contact header field if
> there was
> >> no
> >> Record-Route header f
> >
> > There are three statemenets in the or condition. However,
> if the first
> > is true, and we eliminate the last hop exception and retarget
> > exception, unless there is a protocol error the others will be true
> > too. This is one of many places where sips is just way
> simpler if we
> > do that.
> >
> >> be careful about what to use in the Contact (in case
> Record-Route is
> >> not used for this hop). If the Contact was a SIPS URI,
> it would
> >> mean
> >> that it would only accept mid-dialog requests that are
> over secure
> >> transport end-to-end. Since the Request-URI is in this
> case a SIP
> >> URI, it is quite possible that the UA sending a request to that
> >> URI
> >> may not be able to send requests to SIPS URIs. It is therefore
> >> RECOMMENDED that in this case, the Contact be a SIP
> URI, even if
> >> the
> >> request is sent over a secure transport (e.g., the
> first hop could
> >> be
> >> re-using a TLS connection to the proxy as would be the case with
> >> [I-D.ietf-sip-outbound]).
> >
> > why is this just RECOMMENDED and not MUST?
> >
> >> When a target refresh occurs within a dialog (e.g., re-INVITE,
> >> UPDATE), unless there is a need to change it, the UAC SHOULD
> >> include
> >> a Contact header with a SIPS URI if the original request used a
> >> SIPS
> >> Request-URI.
> >
> > why not MUST?
> >
> >> Sessions, dialogs and transactions may be "derived" from existings
> >> ones.
> >> As a general principle, derived dialogs and transactions SHOULD
> >> NOT
> >> result in an effective downgrading of SIPS to SIP, without the
> >> explicit authorization of the entities involved.
> >
> > unless you formally define 'derived' this is a meaningless
> > requirement.
> >
> >> However, for backward compatibility, if a "transport=tls"
> parameter
> >> is received, it should be interpreted as per the following
> >> guidelines:
> >> o [RFC3261]/16.7 states the transport parameter (e.g.,
> with tcp
> >> or
> >> udp) SHOULD NOT be used in Record-Route unless it
> has knowledge
> >> that the next upstream element that will be in the path of
> >> subsequent supports this transport. Generally, it is
> >> recommended
> >> that the transport parameter never be used in a Record-Route,
> >> Route or Path header. Since the transport=tls URI parameter
> >> has
> >> been deprecated, it MUST NOT be used in Route,
> Record-Route or
> >> Path headers, and MUST be ignored.
> >> o In a Contact in a dialog, it MAY be interpreted as a
> request to
> >> send incoming mid-dialog requests using TLS. Note that this
> >> would
> >> only have a significance if [I-D.ietf-sip-outbound]
> and Record-
> >> Route are not used, and if that URI is nevertheless
> reachable
> >> with
> >> TLS which is extremely unlikely. If it was the case that it
> >> was
> >> reachable with TLS, say because there is an active TLS
> >> connection,
> >
> > the first paragraph says that what follows will be what to
> do if you
> > receive transport=tls, but the first bullet is about sending it. In
> > that paragraph you say its 'recommneded' not to be used in
> RR, Route
> > or Path, and then next sentence is MUST NOT. So which is it?
> >
> > If this is normative do we need to carry forward text on
> transport=tls
> > beyond saying don't send and ignore on receive?
> >
> >
> > Thanks,
> > Jonathan R.
> >
> >
> >
> >
> >
> >
> > --
> > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza
> > Cisco Fellow Parsippany, NJ
> > 07054-2711
> > Cisco Systems
> > [EMAIL PROTECTED] FAX: (973) 952-5050
> > http://www.jdrosen.net PHONE: (973) 952-5000
> > http://www.cisco.com
> >
> > _______________________________________________
> > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol Use
> > [EMAIL PROTECTED] for questions on current sip Use
> > [EMAIL PROTECTED] for new developments on the application of sip
>
>
> _______________________________________________
> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol Use
> [EMAIL PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] for new developments on the application of sip
>
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
