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

[Eric Rescorla <[e-mail]>]

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

> 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.)
>

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.



> 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.
>

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


> --Richard
>
> On Tue, Jul 27, 2021 at 7:08 PM John Mattsson <john.mattsson=
> [e-mail]> wrote:
>
>> westhawk [e-mail] wrote:
>>
>>
>>
>> >> On 26 Jul 2021, at 23:30, Kirsty P <Kirsty.p=[e-mail]> <&lt;Kirsty.p=[e-mail]&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
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>