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

Justin Uberti <juberti@google.com> Thu, 30 July 2020 17:52 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 7E72B3A0CE3 for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 10:52:13 -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 BQbXYmKz0nnB for <avt@ietfa.amsl.com>; Thu, 30 Jul 2020 10:52:11 -0700 (PDT)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 7427B3A0BD4 for <avtcore@ietf.org>; Thu, 30 Jul 2020 10:52:11 -0700 (PDT)
Received: by mail-io1-xd2d.google.com with SMTP id l17so29096775iok.7 for <avtcore@ietf.org>; Thu, 30 Jul 2020 10:52:11 -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=iq1xOdCD7pxNGZJJ8QlF/sYmb3tbMlqt6a7D0DoRPjQ=; b=VjLStWbRr6/MAU9kdoCaXMO94t3zQVYYk1iOEXzd1Kiyl0BjmwbkezbpP62ZGyv7ZQ W46kunQ+8nldHN5RXUcWNXZ2flxhoPMAWxQ5WFAdLLC8yX3C1xTZbTSQXg8TU/bbiqGJ nunBA4FayYd3zVC8ONSjbcJy0AGCBqy/01x6/qiMxpT+8LWdHSEsYl/ma9zAwE0Icuv2 U895yl2qD33iNHgR/5erIdcGnonTMcJz+tdjmsGKBpMMilbg6Q8KwJ+ATZbYhPOrLImy NNbhRRK2/n+MXL0n7TqmFP0LuMkJtw7tjLAXMtUvFuGI8ohobMNPPlF9PtpNurzp/8l8 J7AA==
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=iq1xOdCD7pxNGZJJ8QlF/sYmb3tbMlqt6a7D0DoRPjQ=; b=N636ktSbsHGD7+sMqmLPx7L7b3VkclDjKel0SdBuNXo6vV84Or0zWSkK2FtIv6Lr3b zH08/ZSQjnwPnMhHGWgaA1wx1NzYWLqFs7kWuGdPmT4k2+bLiL3ft2c0x5C22pR+7Chw KSYs7/SCxN34WdWjfL8dBGlXB88U0sNJhiF4n7ZlswBL8HZ1QGFspWvp6e8rLu+fTYsf AzPsOVpduauJHdXAWfYRhDXbCUpcidfPixhwzDRZjJUJSBw/slLyD1Uw103QOdrPapZw jNGnePy1I/u4C9Iv6FXtN6HMOHUhZeKKfbUa9gkaomzFdcCeVNaSQZETRtlpkjqZ4VDi isPQ==
X-Gm-Message-State: AOAM532aygHCmcTJbPjL6e5qP84API52BATElKYyhdJ14psS7ZY0boSl vtj2iN7lWlj+nsFN4g+NwmRd2sbC4Q+V6aih8bS2PX9OHh3u3Q==
X-Google-Smtp-Source: ABdhPJxcWLJdQ7Xyu6i24vlnzTyAwFdcUIckZe+9yuogdUbOQb04vGUXXI1/3vjhP/cDCcK5Cz/rPKhT4fCdI9AK//Q=
X-Received: by 2002:a6b:6303:: with SMTP id p3mr40482239iog.111.1596131530304; Thu, 30 Jul 2020 10:52:10 -0700 (PDT)
MIME-Version: 1.0
References: <5DA92063-55EF-4CB4-A299-2375575A7D11@iii.ca>
In-Reply-To: <5DA92063-55EF-4CB4-A299-2375575A7D11@iii.ca>
From: Justin Uberti <juberti@google.com>
Date: Thu, 30 Jul 2020 10:51:58 -0700
Message-ID: <CAOJ7v-2DmQ+WvXw6L8XEhGUnp+fZ3XcjaECu-zd8nBaqA7gwvg@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: avtcore@ietf.org
Content-Type: multipart/alternative; boundary="000000000000e1674b05abac544a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/z6W7WXBWon1zS83ZHKKSSpzmHks>
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 17:52:14 -0000

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
>