Re: [AVTCORE] Notes from SRTP Header Encryption Side Meeting.

Justin Uberti <juberti@google.com> Thu, 30 July 2020 21:41 UTC

Return-Path: <juberti@google.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8C73A0D24 for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 14:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDWPunXs4WK3 for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 14:41:43 -0700 (PDT)
Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43C4A3A0D1F for <avt@ietf.org>; Thu, 30 Jul 2020 14:41:43 -0700 (PDT)
Received: by mail-io1-xd2f.google.com with SMTP id z6so29834789iow.6 for <avt@ietf.org>; Thu, 30 Jul 2020 14:41:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RGUP+WIW+kHPzMdlGhNkexgmyE7M4zz2qmw2mSz10S0=; b=TsKHnKL2XSuqh/kktWH0/hMi8fPmehuinak9N3vM16GIA/FQIDaZZOBb2Wfr0AxORa MmnklIIdzvcp+jworN+Mv4/1HdbZa3O7ujR/KQodg2DYVuM2hQfkH55EqTDldkB0WPCa ZDOmdvfD7D7v3+1UFdF5wODPk+y5p0YL0fimZx48OSXaQDHyCXPYaMYZy8Xpsj9cT0Fv bgKXKZJW9BJVx6prDIjmv/StyB2iHMUc40+zKoGPvMAceS19rBxu1axeCBJbkx3ipW/q f5aC0sUssQm+KrDldkG7pwa0Hh5+H9A4Ax1xAtwuZQuNDw63qe+n3mVr6nDWlEilw9+k qptA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RGUP+WIW+kHPzMdlGhNkexgmyE7M4zz2qmw2mSz10S0=; b=axpGdz7FHAMvEDp56TvtmdYmZBw6WSVhKL1mmJoy4QCh2lCXD7N1qd5+/nYvRVh3// 9obqUEAANoyRpT7L5OYG4kEn+H5LM5U8NVkLqOHJJYsrFOm5gicdUg/1exNU2YPG2AtW Xflme5e0LBod+CSJX/TjdjYIDN2MpZVm6KjIbKDa1/VGJmdG9qyP5hd9Ilq/hna2BYbb jGIKMg788oQ4HMR/8gO71mMvtftK+E0rPIT+Uo1iLNSe3zm1yo2kb9dxKUZgktVT08RP UV+Z+xfio7yH2cQRrkPbuAX0sjfeE9Hzr6VpcRe+5C+adfEQe8K/Yuqo3SelDsf+36ir 9K5w==
X-Gm-Message-State: AOAM532cF33iFn0usd8zxj08qW/9/keqpOtFCb7qEhRq1wiDBavmTf6F 6ZeTp3uO/D1n4YGkcqKFWmf6mKjkxTAs0LMu8hCjrNny2gw=
X-Google-Smtp-Source: ABdhPJy1/1sh9bqfublr2qhzDEPZEqtN/0keRCsA6lWG9nxiaaM1EETBgWgKCrhi+uDeFdg+iWOSce4QqYxew0V49xc=
X-Received: by 2002:a05:6638:2601:: with SMTP id m1mr1401958jat.141.1596145302107; Thu, 30 Jul 2020 14:41:42 -0700 (PDT)
MIME-Version: 1.0
References: <5DA92063-55EF-4CB4-A299-2375575A7D11@iii.ca> <CAOJ7v-2DmQ+WvXw6L8XEhGUnp+fZ3XcjaECu-zd8nBaqA7gwvg@mail.gmail.com> <821df6c6-7f99-98dc-b4d9-4e1eee0a644b@gmail.com>
In-Reply-To: <821df6c6-7f99-98dc-b4d9-4e1eee0a644b@gmail.com>
From: Justin Uberti <juberti@google.com>
Date: Thu, 30 Jul 2020 14:41:30 -0700
Message-ID: <CAOJ7v-1iaBWVy4SMGPyc=DPPiVqF=QubJYStmN+vtaQC3kpxDQ@mail.gmail.com>
To: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Cc: avt@ietf.org
Content-Type: multipart/alternative; boundary="000000000000be561105abaf891d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/ywLMqY7J7fUDY94MwMqOVZKBW70>
Subject: Re: [AVTCORE] Notes from SRTP Header Encryption Side Meeting.
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2020 21:41:47 -0000

Let's have the discussion on the list, but let's add items to the cryptex
issues list as we define what needs to be done.

I think we'll want an initial draft we can point people at before opening
an issue in the libsrtp repo.

On Thu, Jul 30, 2020 at 1:21 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

> What would be the best way of moving this forward, adding issues to the
> github repo or keep the discussion on the mailing list?
>
> I can volunteer to do the PR against libsrtp too, should we create an
> issue on libsrtp repo for discussing the implementation details?
>
> Best regards
> Sergio
> On 30/07/2020 19:51, Justin Uberti wrote:
>
> Thanks Cullen for taking notes. I've created a repo for the SDP/SRTP doc
> at https://github.com/juberti/cryptex.
>
> On Thu, Jul 30, 2020 at 10:44 AM Cullen Jennings <fluffy@iii.ca> wrote:
>
>>
>> Conclusion from the call:
>> —————————————
>>
>> Option C1 from Justin's slides of encrypt CCRC plus stuff after header
>> extension length was the option people on call were leaning towards.
>>
>> Prefer to negotiate turning this on and off with SDP. (could look at
>> negotiating in DTLS later )
>>
>> For the WebRTC API could do on WebRTC RTCConfiguration API - or WebRTC
>> extension document HTA is writing. ( RTP Header Extension Parameter ). Or
>> it could be on Transceiver with a header policy.
>>
>> Next Steps:
>> —————————————
>>
>> Justin and Cullen take stab at SDP / SRTP doc.
>>
>> Bernard & Sergio to help draft W3C doc.
>>
>> Someone to write a PR for libsrtp. ????
>>
>> Need to improve testing on this. Need reference vectors in spec.
>>
>> Do on avtcore mailing list
>>
>>
>>
>> Notes from Discussion
>> ---------------------------
>>
>>
>> As part of general IETF move towards encryption, there are things in RTP
>> headers we would like to encrypt.
>>
>> RFC 6904 exists. Allows negotiation of each header separately. Probably
>> overkill.  RFC 8285 makes it even more complicated.
>>
>> Implementors view this as complicated and have not spent time on it.
>> Recent bugs in webrtc / libsrp indicate this is not all easy to do.
>>
>> That header IDs are sent as cleartext, it reveals what type of headers
>> you are exchanging, but not the info.
>>
>> Audio Level might want to encrypt over DTLS-SRTP particular in use cases
>> in SFrame.
>>
>> One proposal is start SRTP payload encryption earlier in packet. Say, do
>> all the headers (if it was negotated course ).
>>
>> That leads to encrypt CSRCs, everything from CSRC forward to end of
>> payload..
>>
>> That leads to encrypt everything but v=2, seq num, and ssrc.
>>
>>
>> So the discussion was about how much of the packet do we encrypt?
>>
>>
>> Proposal: Encrypt everything from start of CSRC forward.
>>
>> Proposal: Encrypt everything but V=2, seq num, ssrc.
>>
>> Proposal: Encrypt from after the header extension length
>>
>> Mo points out people look at header extension length.
>>
>> Mo point out setting the x bit to zero for this so things don't try to
>> interpret it.
>>
>>
>> Questions about if changing some of fields would cause firewalls to barf
>> on the packets.
>>
>> We run into problem of how to send x bit when no header extension in a
>> given packet.
>>
>> A key issue with C is what to do if no header extension but do have
>> CSRC.  Possible answer is have to add a null extention to encrypt CCSRC.
>>
>> For WebRTC, would be on by default.
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Audio/Video Transport Core Maintenance
>> avt@ietf.org
>> https://www.ietf.org/mailman/listinfo/avt
>>
>
> _______________________________________________
> Audio/Video Transport Core Maintenanceavt@ietf.orghttps://www.ietf.org/mailman/listinfo/avt
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>