Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes

From: John Mattsson <[email-masked]>
Date: Tue, 27 Jul 2021 23:08:35 +0000

westhawk [email-masked]<mailto:[email-masked]> wrote:

>> On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=[email-masked]><mailto:&lt;Kirsty.p=[email-masked]&gt;> >wrote:

>> SDP Security Descriptions is NOT RECOMMENDED and Historic: consensus was >sub-optimal. There was support for revisiting the space currently standardised >by SDP, but not on direction (whether to do a deprecation with/without >replacement). Future paths suggested included: mmusic, a new WG, more work >required for it to be ready, or a BoF (said in chat) to vet the idea further.

>My sense is that there was a rough consensus around a goal to make it possible >to deprecate SDES - but the required steps were unclear.

Yes, looking at the Jabber log there was quite strong support for the goal of deprecating SDES:

Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a good idea and promote it to full standard toda
Martin Thomson: now that I see John presenting this, I have to wonder: why didn't this deprecation happen before?
Sean Turner: When Dan Wing got up and said not to use SDES in Berlin - I assumed that was that ;)
Pete Resnick: Why "NOT RECOMMENDED" instead of "MUST NOT"?
Sean Turner: +1 to what ekr said
Rich Salz: +1 also

Regarding the next required steps I agree with Pete. Let’s charter.

Ben Kaduk: So is this dispatch to BoF, or straight to WG?
Pete Resnick: @ben: Sounds like this discussion has done the equivalent of BoFing. Charter.

Cheers,
John

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Jul 2021 16:09:53 -0700

On Tue, Jul 27, 2021 at 4:08 PM John Mattsson <john.mattsson=
[email-masked]> wrote:

> westhawk [email-masked] wrote:
>
>
>
> >> On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=[email-masked]> <&lt;Kirsty.p=[email-masked]&gt;> >wrote:
>
> >>
>
> Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is a
> good idea and promote it to full standard toda
>

This was maybe slightly sarcastic but for avoidance of doubt, I strongly
support this work .

-Ekr

Martin Thomson: now that I see John presenting this, I have to wonder: why
> didn't this deprecation happen before?
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 27 Jul 2021 22:13:34 -0600

The jabber chat certainly does not represent the room in any WG I have been in. I do not think the slides represent an accurate summary of the what we are trying to achieve by deprecating SDES or what we would need to do get there and thus don’t lead to a useful input on what to do next or where to dispatch it. 

As I said at the meeting, I am in favor of discussing and solving the problems we need to sort out to have a viable replacement. It is pretty hard to have a conversation about that in 10 minutes when some of the people are arguing that SDES is worse than unencrypted traffic. 

A real good starting point to the conversation would be agreeing about the fundamental differences - in my mind the largest difference is that in DTLS-SRTP, the attacker has to be able to modify the SDP to MITM the media while in SDES the attacker only needs to see the SDP to MITM the media. 

> On Jul 27, 2021, at 5:09 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Tue, Jul 27, 2021 at 4:08 PM John Mattsson <john.mattsson=[email-masked] <mailto:[email-masked]>> wrote:
> westhawk [email-masked] <mailto:[email-masked]> wrote:
> 
>  
> 
> >> On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=[email-masked]> <mailto:&lt;Kirsty.p=[email-masked]&gt;> >wrote:
> >> 
> This was maybe slightly sarcastic but for avoidance of doubt, I strongly support this work .
> 
> -Ekr
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dispatch <https://www.ietf.org/mailman/listinfo/dispatch>

---

From: westhawk <[email-masked]>
Date: Wed, 28 Jul 2021 16:33:52 +0200

> On 28 Jul 2021, at 06:13, Cullen Jennings <[email-masked]> wrote:
> 
> As I said at the meeting, I am in favor of discussing and solving the problems we need to sort out to have a viable replacement.

I didn’t hear any criteria for judging  a replacement’s viablility .
I did hear "carriers won’t move from SDES” and “The Queen uses SDES” (paraphrased)
It seems unlikely any replacement can overcome those two objections. 

Tim.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Jul 2021 13:26:06 -0400

I hate sending symmetric keys around as much as the next person.  But we
should be pragmatic here.

The situation with SDES is unlike the situation with a bunch of the other
deprecations we have done recently (SSLv3, TLS 1.0).  There, the protocol
was broken, in the sense that it does not provide the guarantees that it is
supposed to provide.  Here, SDES still does what it says on the label, just
like it always has; we’re just increasingly grumpy about that model and
there are somewhat better alternatives.

Note “somewhat” — DTLS-SRTP is only better than SDES to the extent that the
certificates in the DTLS exchange are verified independent of the signaling
path.  If you rely only on the fingerprint in SDP for authentication, then
an SDP-path entity can swap out fingerprints to intercept get keys just as
well as with SDES.  (At best, this swaps an active for a passive attack,
which is not nothing, but not a huge step.)  We do have mechanisms for such
verification, but they’re not widely deployed.

All of which tells me that there's not an urgent need for action here.
SDES is not a looming threat to the Internet.  In the many deployments
where it is used, it still does what it claims to do, and people have
accommodated that into their broader system models.  Even if there were to
be a mass migration to DTLS-SRTP, the actual security benefit for all that
work would be fairly minor until we do a lot more work to solve the
authentication problems.

So if folks want to make a bigger, scarier warning label to put on SDES to
guide people away from it, sure, fine.  But it doesn’t seem like a blaring
red warning light is called for.  In terms of this document, the content is
probably mostly OK if we reframe it in that light.  Obsoleting SDES and
marking it Historic, though, is over the top; it will just create
unnecessary consternation.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jul 2021 10:32:08 -0700

On Wed, Jul 28, 2021 at 10:26 AM Richard Barnes <[email-masked]> wrote:

> Note “somewhat” — DTLS-SRTP is only better than SDES to the extent that
> the certificates in the DTLS exchange are verified independent of the
> signaling path.  If you rely only on the fingerprint in SDP for
> authentication, then an SDP-path entity can swap out fingerprints to
> intercept get keys just as well as with SDES.  (At best, this swaps an
> active for a passive attack, which is not nothing, but not a huge step.)
>

Well, we don't really have a definition for "huge", but:

1. I don't think swapping a passive attack for an active attack is trivial.
After all, that's much of the premise of 7258.
2. It's not just a matter of "passive attack" but rather of the fact that
SDES turns any logs/debugging/traffic monitoring/etc. that contains the SDP
into toxic waste that has to be carefully guarded.

> unnecessary consternation.

I'm not really following your argument here. We all agree that (1) SDES is
bad (2) We have better alternatives in the form of DTLS-SRTP and
(eventually) MLS-SRTP. So, precisely what harm is it doing to tell people
that and that they shouldn't use SDES in favor of that. "consternation" is
not a real harm.

-Ekr

>> Martin Thomson: now that I see John presenting this, I have to wonder:
>> why didn't this deprecation happen before?

---

From: Richard Barnes <[email-masked]>
Date: Wed, 28 Jul 2021 13:59:08 -0400

On Wed, Jul 28, 2021 at 1:32 PM Eric Rescorla <[email-masked]> wrote:

>
>
>> So if folks want to make a bigger, scarier warning label to put on SDES
>> to guide people away from it, sure, fine.  But it doesn’t seem like a
>> blaring red warning light is called for.  In terms of this document, the
>> content is probably mostly OK if we reframe it in that light.  Obsoleting
>> SDES and marking it Historic, though, is over the top; it will just create

We agree with regard to the future.

What are operators of existing systems using SDES supposed to take away
from this?  This is not like say the SSLv3 deprecation where we had new
data (POODLE) that changed the posture of these systems.  Systems based on
SDES are as secure / insecure as they ever were.  So what I'm worried about
is (a) the IETF looking alarmist for marking a bunch of things insecure
that are actually fine, and (b) to the degree the deprecation is taken
seriously, creating a bunch of work to upgrade from SDES to a flavor of
DTLS-SRTP that is not enough better to merit the effort.

--Richard

>>> Eric Rescorla: Let's all just agree that this (Mattson's SDES) draft is
>>> a good idea and promote it to full standard toda

---

From: John Mattsson <[email-masked]>
Date: Wed, 28 Jul 2021 18:47:30 +0000

Richard Barnes <[email-masked]> wrote:

> I hate sending symmetric keys around as much as the next person.  But we should be pragmatic here.

I think the NOT RECOMMENDED suggestion on the table is quite pragmatic. The suggestions here are much softer than the RFC 8996: "MUST NOT negotiate TLS 1.1".

> Here, SDES still does what it says on the label

I don't think that is true. SDES is labeled as an IETF proposed standard. It might barely have met the requirements for that when it was published, but it certainly does not anymore. While SDES is as insecure as it always has been, the distance between SDES and what is considered acceptable security has grown big.

-John

From: Richard Barnes <[email-masked]>
Date: Wednesday, 28 July 2021 at 19:26
To: John Mattsson <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: [dispatch] DISPATCH IETF 111 meeting - preliminary outcomes and draft minutes
I hate sending symmetric keys around as much as the next person.  But we should be pragmatic here.

The situation with SDES is unlike the situation with a bunch of the other deprecations we have done recently (SSLv3, TLS 1.0).  There, the protocol was broken, in the sense that it does not provide the guarantees that it is supposed to provide.  Here, SDES still does what it says on the label, just like it always has; we’re just increasingly grumpy about that model and there are somewhat better alternatives.

Note “somewhat” — DTLS-SRTP is only better than SDES to the extent that the certificates in the DTLS exchange are verified independent of the signaling path.  If you rely only on the fingerprint in SDP for authentication, then an SDP-path entity can swap out fingerprints to intercept get keys just as well as with SDES.  (At best, this swaps an active for a passive attack, which is not nothing, but not a huge step.)  We do have mechanisms for such verification, but they’re not widely deployed.

All of which tells me that there's not an urgent need for action here.  SDES is not a looming threat to the Internet.  In the many deployments where it is used, it still does what it claims to do, and people have accommodated that into their broader system models.  Even if there were to be a mass migration to DTLS-SRTP, the actual security benefit for all that work would be fairly minor until we do a lot more work to solve the authentication problems.

So if folks want to make a bigger, scarier warning label to put on SDES to guide people away from it, sure, fine.  But it doesn’t seem like a blaring red warning light is called for.  In terms of this document, the content is probably mostly OK if we reframe it in that light.  Obsoleting SDES and marking it Historic, though, is over the top; it will just create unnecessary consternation.

--Richard

On Tue, Jul 27, 2021 at 7:08 PM John Mattsson <john.mattsson=[email-masked]<mailto:[email-masked]>> wrote:

Cheers,
John
_______________________________________________
dispatch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dispatch

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jul 2021 12:03:19 -0700

On Wed, Jul 28, 2021 at 10:59 AM Richard Barnes <[email-masked]> wrote:

>> I'm not really following your argument here. We all agree that (1) SDES
>> is bad (2) We have better alternatives in the form of DTLS-SRTP and
> SDES are as secure / insecure as they ever were.
>

What's changed is (1) a clearer appreciation of the threat model and (2)
more widespread availability of better technologies.

So what I'm worried about is (a) the IETF looking alarmist for marking a
> bunch of things insecure that are actually fine,
>

The point, as John has ably documented, is that they're not fine.

and (b) to the degree the deprecation is taken seriously, creating a bunch
> of work to upgrade from SDES to a flavor of DTLS-SRTP that is not enough
> better to merit the effort.
>

It seems to me that replacing SDES with DTLS-SRTP (or, I guess, MLS-SRTP)
is precisely the intended outcome here.

-Ekr