From nobody Mon Aug 1 13:37:52 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D27512D865 for ; Mon, 1 Aug 2016 13:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 LNdhel932Oe8 for ; Mon, 1 Aug 2016 13:37:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D7E4812D837 for ; Mon, 1 Aug 2016 13:37:47 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u71Kbk00063226 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 1 Aug 2016 15:37:47 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Cullen Jennings References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> From: Adam Roach Message-ID: <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> Date: Mon, 1 Aug 2016 15:37:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> Content-Type: multipart/alternative; boundary="------------C8801841B1D034197460E6E0" Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 20:37:50 -0000 This is a multi-part message in MIME format. --------------C8801841B1D034197460E6E0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We had a discussion on this during the face-to-face in Berlin. The general conclusion from that discussion was to go in the general direction that Cullen outlines below: we create a single TLS/TCP connection from the KMF towards the MDD. Over that connection, we use a simple encapsulation protocol that allows us to exchange multiple flows of TLS traffic, along with some control messages (supported ciphersuites, HBH keys). This leaves us to decide the syntax for this framing (I fear this is kind of bikesheddy, but we need to nail it down). So far I've heard three basic suggestions: 1. Hand-roll our own protocol, similar to what is currently in the tunnel draft. 2. Use JSON [RFC7159] 3. Use CBOR [RFC7049] Presumably, the JSON representation would look something like: { "type": "tunnel", "channel": 4, "packet": "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEARI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBiAGEAFQASAAkAZQ BkAGAAFAARAAgABgADAQA=" } { "type": "profiles", "supported": [7,8] } { "type": "keys", "channel": 4, "profile": 8, "mki": 17, "server_key": "...", "server_salt": "...", "client_key": "...", "server_salt": "..." } (The "..." above are base-64 encoded values) And the CBOR representation would simply encode these structures in CBOR, using literal byte strings rather than base64 for the packets, keys, and salts, and integers to encode packet types. I have a slight preference for CBOR (it's more general than a custom scheme, and more compact than JSON), but nothing extremely strong. /a On 7/18/16 07:02, Cullen Jennings wrote: > So agree that snag kills the current plan. > > Running a webrtc data channel looks like the most hideously complicated thing we could do. How about we just use a TLS connection made from the KMF to the MDD? I don’t think the head of line issue or the putting the MDD behind a NAT are practical enough use cases to justify the complexity. > > > > >> On Jul 16, 2016, at 4:39 AM, Adam Roach wrote: >> >> Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD. >> >> Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist. >> >> This means that we'll need some additional reliability mechanism. >> >> We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >> >> * ICE gives us the keepalives we need to maintain NAT and firewall >> pinholes >> * ICE provides a means for finding which of UDP or TCP will work >> through the firewall >> * SCTP provides reliability for exchanging messages pertaining to >> supported ciphersuites and hop-by-hop keys >> * SCTP provides multiple channels that can be used to carry multiple >> DTLS associations >> >> Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address. >> >> >> +------+------+------+------+ >> | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >> +------+------+------+------+ >> | SCTP | <- Provides control channel reliability, channel IDs >> +---------------------------+ >> | DTLS | <- DTLS here is the KMF <-> MDD connection >> +---------------------------+ >> | ICE | <- Provides keepalives, firewall traversal >> +---------------------------+ >> | UDP or TCP | >> +---------------------------+ >> >> >> I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement. >> >> /a >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc --------------C8801841B1D034197460E6E0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
We had a discussion on this during the face-to-face in Berlin. The general conclusion from that discussion was to go in the general direction that Cullen outlines below: we create a single TLS/TCP connection from the KMF towards the MDD. Over that connection, we use a simple encapsulation protocol that allows us to exchange multiple flows of TLS traffic, along with some control messages (supported ciphersuites, HBH keys).

This leaves us to decide the syntax for this framing (I fear this is kind of bikesheddy, but we need to nail it down). So far I've heard three basic suggestions:
  1. Hand-roll our own protocol, similar to what is currently in the tunnel draft.
  2. Use JSON [RFC7159]
  3. Use CBOR [RFC7049]

Presumably, the JSON representation would look something like:

{
  "type": "tunnel",
  "channel": 4,
  "packet": "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEARI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ
    LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBiAGEAFQASAAkAZQ
    BkAGAAFAARAAgABgADAQA="
}

{
  "type": "profiles",
  "supported": [7,8]
}

{
  "type": "keys",
  "channel": 4,
  "profile": 8,
  "mki": 17,
  "server_key": "...",
  "server_salt": "...",
  "client_key": "...",
  "server_salt": "..."
}

(The "..." above are base-64 encoded values)

And the CBOR representation would simply encode these structures in CBOR, using literal byte strings rather than base64 for the packets, keys, and salts, and integers to encode packet types.

I have a slight preference for CBOR (it's more general than a custom scheme, and more compact than JSON), but nothing extremely strong.

/a

On 7/18/16 07:02, Cullen Jennings wrote:
So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thing we could do.  How about we just use a TLS connection made from the KMF to the MDD? I don’t think the head of line issue or the putting the MDD behind a NAT are practical enough use cases to justify the complexity. 





On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com> wrote:

Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD.

Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist.

This means that we'll need some additional reliability mechanism.

We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone:

* ICE gives us the keepalives we need to maintain NAT and firewall
  pinholes
* ICE provides a means for finding which of UDP or TCP will work
  through the firewall
* SCTP provides reliability for exchanging messages pertaining to
  supported ciphersuites and hop-by-hop keys
* SCTP provides multiple channels that can be used to carry multiple
  DTLS associations

Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address.


+------+------+------+------+
| Ctrl | DTLS | DTLS | DTLS |  <- DTLS for DTLS-SRTP terminates here
+------+------+------+------+
|           SCTP            |  <- Provides control channel reliability, channel IDs
+---------------------------+
|           DTLS            |  <- DTLS here is the KMF <-> MDD connection
+---------------------------+
|           ICE             |  <- Provides keepalives, firewall traversal
+---------------------------+
|        UDP or TCP         |
+---------------------------+


I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement.

/a

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


--------------C8801841B1D034197460E6E0-- From nobody Mon Aug 1 14:46:20 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B3112D150 for ; Mon, 1 Aug 2016 14:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 WaswqKx-SNBl for ; Mon, 1 Aug 2016 14:46:17 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3692212D0EC for ; Mon, 1 Aug 2016 14:46:17 -0700 (PDT) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-09v.sys.comcast.net with SMTP id UL1ebgQwa1XXBUL2Ob8VRq; Mon, 01 Aug 2016 21:46:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by comcast with SMTP id UL2MbIDXsMJgPUL2NbUWXp; Mon, 01 Aug 2016 21:46:16 +0000 To: perc@ietf.org References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> From: Paul Kyzivat Message-ID: Date: Mon, 1 Aug 2016 17:46:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJsQoDD2oED2YAGC+FkfAqV9piJ8rm7CpKH+WyIyXAB+jvSYtdThPsgj8g8hj1e+2jcA3/4P3seu8boBlQTAs3xhz4ks6XpEWCQXpmff7eA7mELsxtZv 36gHuUGyP4xFmAeifLKuocTV3cnrPyl+UmBVRKVsUnXYlQQu9VWUoCBAigO/0Imu1rvzMaSVhJyFhg== Archived-At: Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 21:46:18 -0000 On 8/1/16 4:37 PM, Adam Roach wrote: > We had a discussion on this during the face-to-face in Berlin. The > general conclusion from that discussion was to go in the general > direction that Cullen outlines below: we create a single TLS/TCP > connection from the KMF towards the MDD. Hasn't there been discussion that one of the participants might be serving as KMF? And hasn't there been hope that webrtc clients might be able to be participants? If so, IIUC webrtc clients typically can't set up a naked TLS connection. The best they can do is websockets. Thanks, Paul From nobody Mon Aug 1 16:02:37 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A6312D65E for ; Mon, 1 Aug 2016 16:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 GWVEddih1O2Z for ; Mon, 1 Aug 2016 16:02:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 2C63C12D112 for ; Mon, 1 Aug 2016 16:02:35 -0700 (PDT) Received: from [26.155.12.162] ([172.56.7.120]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u71N2UUF075597 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 1 Aug 2016 18:02:32 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [172.56.7.120] claimed to be [26.155.12.162] References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (13F69) From: Adam Roach Date: Mon, 1 Aug 2016 18:02:24 -0500 To: Paul Kyzivat Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 23:02:36 -0000 The KMF in that case would be a function embedded in the web browser that th= e content can activate. The content itself can't serve as a KMF, because tha= t would give it access to the keying material, which it could exfiltrate bac= k to the service.=20 /a > On Aug 1, 2016, at 16:46, Paul Kyzivat wrote: >=20 >> On 8/1/16 4:37 PM, Adam Roach wrote: >> We had a discussion on this during the face-to-face in Berlin. The >> general conclusion from that discussion was to go in the general >> direction that Cullen outlines below: we create a single TLS/TCP >> connection from the KMF towards the MDD. >=20 > Hasn't there been discussion that one of the participants might be serving= as KMF? And hasn't there been hope that webrtc clients might be able to be p= articipants? >=20 > If so, IIUC webrtc clients typically can't set up a naked TLS connection. T= he best they can do is websockets. >=20 > Thanks, > Paul >=20 > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc From nobody Tue Aug 2 12:01:15 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CA412D8A9 for ; Tue, 2 Aug 2016 12:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ZS8r3f96WfDj for ; Tue, 2 Aug 2016 12:01:12 -0700 (PDT) Received: from smtp85.iad3a.emailsrvr.com (smtp85.iad3a.emailsrvr.com [173.203.187.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A935612D8B4 for ; Tue, 2 Aug 2016 12:01:03 -0700 (PDT) Received: from smtp11.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id E8D72A0236; Tue, 2 Aug 2016 15:01:00 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6CD90A059A; Tue, 2 Aug 2016 15:01:00 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Tue, 02 Aug 2016 15:01:00 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> Date: Tue, 2 Aug 2016 13:00:59 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:01:14 -0000 CBOR would be the worst of both worlds. Prefer the other approaches.=20 > On Aug 1, 2016, at 2:37 PM, Adam Roach wrote: >=20 > We had a discussion on this during the face-to-face in Berlin. The = general conclusion from that discussion was to go in the general = direction that Cullen outlines below: we create a single TLS/TCP = connection from the KMF towards the MDD. Over that connection, we use a = simple encapsulation protocol that allows us to exchange multiple flows = of TLS traffic, along with some control messages (supported = ciphersuites, HBH keys). >=20 > This leaves us to decide the syntax for this framing (I fear this is = kind of bikesheddy, but we need to nail it down). So far I've heard = three basic suggestions: > =E2=80=A2 Hand-roll our own protocol, similar to what is = currently in the tunnel draft. > =E2=80=A2 Use JSON [RFC7159] > =E2=80=A2 Use CBOR [RFC7049] > Presumably, the JSON representation would look something like: >=20 > { > "type": "tunnel", > "channel": 4, > "packet": = "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEARI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ > = LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBiAGEAFQASAAkAZQ > BkAGAAFAARAAgABgADAQA=3D" > } > { > "type": "profiles", > "supported": [7,8] > } >=20 > { > "type": "keys", > "channel": 4, > "profile": 8, > "mki": 17, > "server_key": "...", > "server_salt": "...", > "client_key": "...", > "server_salt": "..." > } >=20 > (The "..." above are base-64 encoded values) >=20 > And the CBOR representation would simply encode these structures in = CBOR, using literal byte strings rather than base64 for the packets, = keys, and salts, and integers to encode packet types. >=20 > I have a slight preference for CBOR (it's more general than a custom = scheme, and more compact than JSON), but nothing extremely strong. >=20 > /a >=20 > On 7/18/16 07:02, Cullen Jennings wrote: >> So agree that snag kills the current plan. >>=20 >> Running a webrtc data channel looks like the most hideously = complicated thing we could do. How about we just use a TLS connection = made from the KMF to the MDD? I don=E2=80=99t think the head of line = issue or the putting the MDD behind a NAT are practical enough use cases = to justify the complexity.=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> On Jul 16, 2016, at 4:39 AM, Adam Roach >>> wrote: >>>=20 >>> Mozilla has started looking into implementation of a PERC KMF, and = have run into a bit of a snag with the tunnel protocol. Right now, the = current tunnel i-d plans on using the reliability of the underlying TLS = handshake (client hello/server hello/finished/finished) to ensure that = required information is exchanged between the KMF and the MDD. >>>=20 >>> Unfortunately, this won't work. The *reason* it won't work is that = TLS 1.3 (which we'll certainly want to support) performs a three-way = handshake instead of a four-way handshake. So the message that we = planned to use to send the HBH key from the KMF to the MDD simply = doesn't exist. >>>=20 >>> This means that we'll need some additional reliability mechanism. >>>=20 >>> We can roll our own -- but (as SIP taught us) that's not an awesome = thing to do -- or we can re-use something that already works. As we = worked through how best to do this, something relatively simple = presented itself. If we use a stack similar to what we're using for = WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >>>=20 >>> * ICE gives us the keepalives we need to maintain NAT and firewall >>> pinholes >>> * ICE provides a means for finding which of UDP or TCP will work >>> through the firewall >>> * SCTP provides reliability for exchanging messages pertaining to >>> supported ciphersuites and hop-by-hop keys >>> * SCTP provides multiple channels that can be used to carry multiple >>> DTLS associations >>>=20 >>> Basically, this means we move away from a custom binary protocol for = the tunnel and re-use existing designs. It's easier to specify, and (at = least, for the architectures we've been considering) much easier to = implement. It's worth noting that the MDD would only need to support = ice-lite, assuming it's deployed on a publicly-routable address. >>>=20 >>>=20 >>> +------+------+------+------+ >>> | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >>> +------+------+------+------+ >>> | SCTP | <- Provides control channel = reliability, channel IDs >>> +---------------------------+ >>> | DTLS | <- DTLS here is the KMF <-> MDD = connection >>> +---------------------------+ >>> | ICE | <- Provides keepalives, firewall = traversal >>> +---------------------------+ >>> | UDP or TCP | >>> +---------------------------+ >>>=20 >>>=20 >>> I know it's kind of a step back from the tunnel protocol we've been = designing at so far, but it looks a lot cleaner, and allows for re-use = of already debugged components that will largely exist in = implementations (or that can be trivially sourced from = commercially-friendly open source projects). Overall -- and in addition = to the other advantages -- I think this will be easier to specify and = easier to implement. >>>=20 >>> /a >>>=20 >>> _______________________________________________ >>> Perc mailing list >>>=20 >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc >> _______________________________________________ >> Perc mailing list >>=20 >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >=20 From nobody Tue Aug 2 12:02:50 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E41212D8AB for ; Tue, 2 Aug 2016 12:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 xFrWac43OW0Z for ; Tue, 2 Aug 2016 12:02:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 86F5A12D8B0 for ; Tue, 2 Aug 2016 12:02:46 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u72J2jra083198 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Aug 2016 14:02:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Cullen Jennings References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> From: Adam Roach Message-ID: <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> Date: Tue, 2 Aug 2016 14:02:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:02:49 -0000 Like I said, I don't feel strongly about it. JSON would be my second choice. It's verbose, but this is going to be a low-traffic interface, so it doesn't bother me too much. /a On 8/2/16 14:00, Cullen Jennings wrote: > CBOR would be the worst of both worlds. Prefer the other approaches. > >> On Aug 1, 2016, at 2:37 PM, Adam Roach wrote: >> >> We had a discussion on this during the face-to-face in Berlin. The general conclusion from that discussion was to go in the general direction that Cullen outlines below: we create a single TLS/TCP connection from the KMF towards the MDD. Over that connection, we use a simple encapsulation protocol that allows us to exchange multiple flows of TLS traffic, along with some control messages (supported ciphersuites, HBH keys). >> >> This leaves us to decide the syntax for this framing (I fear this is kind of bikesheddy, but we need to nail it down). So far I've heard three basic suggestions: >> • Hand-roll our own protocol, similar to what is currently in the tunnel draft. >> • Use JSON [RFC7159] >> • Use CBOR [RFC7049] >> Presumably, the JSON representation would look something like: >> >> { >> "type": "tunnel", >> "channel": 4, >> "packet": "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEARI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ >> LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBiAGEAFQASAAkAZQ >> BkAGAAFAARAAgABgADAQA=" >> } >> { >> "type": "profiles", >> "supported": [7,8] >> } >> >> { >> "type": "keys", >> "channel": 4, >> "profile": 8, >> "mki": 17, >> "server_key": "...", >> "server_salt": "...", >> "client_key": "...", >> "server_salt": "..." >> } >> >> (The "..." above are base-64 encoded values) >> >> And the CBOR representation would simply encode these structures in CBOR, using literal byte strings rather than base64 for the packets, keys, and salts, and integers to encode packet types. >> >> I have a slight preference for CBOR (it's more general than a custom scheme, and more compact than JSON), but nothing extremely strong. >> >> /a >> >> On 7/18/16 07:02, Cullen Jennings wrote: >>> So agree that snag kills the current plan. >>> >>> Running a webrtc data channel looks like the most hideously complicated thing we could do. How about we just use a TLS connection made from the KMF to the MDD? I don’t think the head of line issue or the putting the MDD behind a NAT are practical enough use cases to justify the complexity. >>> >>> >>> >>> >>> >>>> On Jul 16, 2016, at 4:39 AM, Adam Roach >>>> wrote: >>>> >>>> Mozilla has started looking into implementation of a PERC KMF, and have run into a bit of a snag with the tunnel protocol. Right now, the current tunnel i-d plans on using the reliability of the underlying TLS handshake (client hello/server hello/finished/finished) to ensure that required information is exchanged between the KMF and the MDD. >>>> >>>> Unfortunately, this won't work. The *reason* it won't work is that TLS 1.3 (which we'll certainly want to support) performs a three-way handshake instead of a four-way handshake. So the message that we planned to use to send the HBH key from the KMF to the MDD simply doesn't exist. >>>> >>>> This means that we'll need some additional reliability mechanism. >>>> >>>> We can roll our own -- but (as SIP taught us) that's not an awesome thing to do -- or we can re-use something that already works. As we worked through how best to do this, something relatively simple presented itself. If we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >>>> >>>> * ICE gives us the keepalives we need to maintain NAT and firewall >>>> pinholes >>>> * ICE provides a means for finding which of UDP or TCP will work >>>> through the firewall >>>> * SCTP provides reliability for exchanging messages pertaining to >>>> supported ciphersuites and hop-by-hop keys >>>> * SCTP provides multiple channels that can be used to carry multiple >>>> DTLS associations >>>> >>>> Basically, this means we move away from a custom binary protocol for the tunnel and re-use existing designs. It's easier to specify, and (at least, for the architectures we've been considering) much easier to implement. It's worth noting that the MDD would only need to support ice-lite, assuming it's deployed on a publicly-routable address. >>>> >>>> >>>> +------+------+------+------+ >>>> | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >>>> +------+------+------+------+ >>>> | SCTP | <- Provides control channel reliability, channel IDs >>>> +---------------------------+ >>>> | DTLS | <- DTLS here is the KMF <-> MDD connection >>>> +---------------------------+ >>>> | ICE | <- Provides keepalives, firewall traversal >>>> +---------------------------+ >>>> | UDP or TCP | >>>> +---------------------------+ >>>> >>>> >>>> I know it's kind of a step back from the tunnel protocol we've been designing at so far, but it looks a lot cleaner, and allows for re-use of already debugged components that will largely exist in implementations (or that can be trivially sourced from commercially-friendly open source projects). Overall -- and in addition to the other advantages -- I think this will be easier to specify and easier to implement. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>> _______________________________________________ >>> Perc mailing list >>> >>> Perc@ietf.org >>> https://www.ietf.org/mailman/listinfo/perc From nobody Tue Aug 2 12:15:34 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1810F12D8E8 for ; Tue, 2 Aug 2016 12:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 sdln38j779T7 for ; Tue, 2 Aug 2016 12:15:27 -0700 (PDT) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 72E7D12D8E7 for ; Tue, 2 Aug 2016 12:15:26 -0700 (PDT) Received: by mail-vk0-x231.google.com with SMTP id s189so129853957vkh.1 for ; Tue, 02 Aug 2016 12:15:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pCR8xOmZWTNDDPZ5bqU2QPlBFv0FH6oUNrfEgd4B7W0=; b=tHNa1mdDviQuzAk9Qf8iByunGwerHF3BCnGTLnALZYRj1YYInZuTJSrjJC4iSAMqfk VsHlsQYhuMmRBSChqLvQtkIW3VLPMYfGPCCXz1y2a80SRExpiOI0cOmlee7evQTxGSeq lG+FmqI5GK5TX2C2ORJ8Szs7ower44BWekyhy0BvpXgTTO18F72rs3xTCowtTZshBeW8 XRfig3YwrvKs/imEwW41XSmK1GZtsVy8LJN7tvX+JUHKquXhhs0NKkWT22SQiZ52ysjD MMtywFz5IyvEgAxer5troQkh12W3L5ydBfou1ocKkwoJ7Y8/bIj/HWWEiSy+HmMSAlRP DfPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pCR8xOmZWTNDDPZ5bqU2QPlBFv0FH6oUNrfEgd4B7W0=; b=GD/wRffSGPF9rYpoTcOackrZtB4wd1oy+jxnQORRrwbreUVrBd2dz3AGqCfgQuHlKr +EbT83W5kt7NJ0uNv/7g5wjWt7lbYrHHWEe9ZJEv7oFDlTQhOyKmO9mFsjzBILplUvPP BcNjEJE7sZ/Pz/ERrAkJ7Ec0PlCygOvinF8QI0wh77eBxn7/L8Qp5BdaT5dHY8pv/5+9 0jOFqFCuVJAQZD4ACncVJ5ljZnHXIqE9nJiydO2R7zoLEBTzJHow7olm45ySjCU6wPyH CtAQTv18MPqVmXlL5AzA9ZMReL/HW5WhWA8YpFurVRH2QWAAdDpM2mKc6fWHQ+uhEMbQ UOkA== X-Gm-Message-State: AEkooutGO+4qxpgtX7NEGp+cc/+/LRG7I3uO0dKowtprohSb3bXTIAGjOjq3iH7wst6eUOfqwuQWsuB4J3HyCw== X-Received: by 10.31.190.131 with SMTP id o125mr30882813vkf.102.1470165325452; Tue, 02 Aug 2016 12:15:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.49.212 with HTTP; Tue, 2 Aug 2016 12:15:24 -0700 (PDT) In-Reply-To: <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> From: Richard Barnes Date: Tue, 2 Aug 2016 15:15:24 -0400 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a11c0b166fc385e05391b89ec Archived-At: Cc: "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:15:29 -0000 --001a11c0b166fc385e05391b89ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This may have been raised and rebutted already, but have we considered WebSockets? Yes, the handshake and framing is a little clumsy, but it seems to meet the basic requirements here: 1. Reliable, secure transport 2. Message framing 3. Direct representation of both binary and text data 4. Ability for either side to send messages at any time With that, you could just say: a. Any binary frame is a 4-byte connection ID followed by a DTLS message b. Any text frame MDD -> KMF is a JSON message with capabilities c. Any text frame KMF -> MDD is a JSON message with keys It seems like that would maximize the "just glue some libraries together and don't do any custom parsing" factor here. Your KMF-side tunnel implementation just glues a WebSocket libary to a JSON parser and a DTLS stack, and the likewise on the MDD side. On Tue, Aug 2, 2016 at 3:02 PM, Adam Roach wrote: > Like I said, I don't feel strongly about it. JSON would be my second > choice. It's verbose, but this is going to be a low-traffic interface, so > it doesn't bother me too much. > > /a > > > On 8/2/16 14:00, Cullen Jennings wrote: > >> CBOR would be the worst of both worlds. Prefer the other approaches. >> >> On Aug 1, 2016, at 2:37 PM, Adam Roach wrote: >>> >>> We had a discussion on this during the face-to-face in Berlin. The >>> general conclusion from that discussion was to go in the general direct= ion >>> that Cullen outlines below: we create a single TLS/TCP connection from = the >>> KMF towards the MDD. Over that connection, we use a simple encapsulatio= n >>> protocol that allows us to exchange multiple flows of TLS traffic, alon= g >>> with some control messages (supported ciphersuites, HBH keys). >>> >>> This leaves us to decide the syntax for this framing (I fear this is >>> kind of bikesheddy, but we need to nail it down). So far I've heard thr= ee >>> basic suggestions: >>> =E2=80=A2 Hand-roll our own protocol, similar to what is curren= tly in >>> the tunnel draft. >>> =E2=80=A2 Use JSON [RFC7159] >>> =E2=80=A2 Use CBOR [RFC7049] >>> Presumably, the JSON representation would look something like: >>> >>> { >>> "type": "tunnel", >>> "channel": 4, >>> "packet": >>> "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEARI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ >>> >>> LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBiAGEAFQASAAkAZQ >>> BkAGAAFAARAAgABgADAQA=3D" >>> } >>> { >>> "type": "profiles", >>> "supported": [7,8] >>> } >>> >>> { >>> "type": "keys", >>> "channel": 4, >>> "profile": 8, >>> "mki": 17, >>> "server_key": "...", >>> "server_salt": "...", >>> "client_key": "...", >>> "server_salt": "..." >>> } >>> >>> (The "..." above are base-64 encoded values) >>> >>> And the CBOR representation would simply encode these structures in >>> CBOR, using literal byte strings rather than base64 for the packets, ke= ys, >>> and salts, and integers to encode packet types. >>> >>> I have a slight preference for CBOR (it's more general than a custom >>> scheme, and more compact than JSON), but nothing extremely strong. >>> >>> /a >>> >>> On 7/18/16 07:02, Cullen Jennings wrote: >>> >>>> So agree that snag kills the current plan. >>>> >>>> Running a webrtc data channel looks like the most hideously complicate= d >>>> thing we could do. How about we just use a TLS connection made from t= he >>>> KMF to the MDD? I don=E2=80=99t think the head of line issue or the pu= tting the MDD >>>> behind a NAT are practical enough use cases to justify the complexity. >>>> >>>> >>>> >>>> >>>> >>>> On Jul 16, 2016, at 4:39 AM, Adam Roach >>>>> wrote: >>>>> >>>>> Mozilla has started looking into implementation of a PERC KMF, and >>>>> have run into a bit of a snag with the tunnel protocol. Right now, th= e >>>>> current tunnel i-d plans on using the reliability of the underlying T= LS >>>>> handshake (client hello/server hello/finished/finished) to ensure tha= t >>>>> required information is exchanged between the KMF and the MDD. >>>>> >>>>> Unfortunately, this won't work. The *reason* it won't work is that TL= S >>>>> 1.3 (which we'll certainly want to support) performs a three-way hand= shake >>>>> instead of a four-way handshake. So the message that we planned to us= e to >>>>> send the HBH key from the KMF to the MDD simply doesn't exist. >>>>> >>>>> This means that we'll need some additional reliability mechanism. >>>>> >>>>> We can roll our own -- but (as SIP taught us) that's not an awesome >>>>> thing to do -- or we can re-use something that already works. As we w= orked >>>>> through how best to do this, something relatively simple presented it= self. >>>>> If we use a stack similar to what we're using for WebRTC >>>>> (SCTP/DTLS/ICE/UDP), we can kill several birds with one stone: >>>>> >>>>> * ICE gives us the keepalives we need to maintain NAT and firewall >>>>> pinholes >>>>> * ICE provides a means for finding which of UDP or TCP will work >>>>> through the firewall >>>>> * SCTP provides reliability for exchanging messages pertaining to >>>>> supported ciphersuites and hop-by-hop keys >>>>> * SCTP provides multiple channels that can be used to carry multiple >>>>> DTLS associations >>>>> >>>>> Basically, this means we move away from a custom binary protocol for >>>>> the tunnel and re-use existing designs. It's easier to specify, and (= at >>>>> least, for the architectures we've been considering) much easier to >>>>> implement. It's worth noting that the MDD would only need to support >>>>> ice-lite, assuming it's deployed on a publicly-routable address. >>>>> >>>>> >>>>> +------+------+------+------+ >>>>> | Ctrl | DTLS | DTLS | DTLS | <- DTLS for DTLS-SRTP terminates here >>>>> +------+------+------+------+ >>>>> | SCTP | <- Provides control channel >>>>> reliability, channel IDs >>>>> +---------------------------+ >>>>> | DTLS | <- DTLS here is the KMF <-> MDD >>>>> connection >>>>> +---------------------------+ >>>>> | ICE | <- Provides keepalives, firewall >>>>> traversal >>>>> +---------------------------+ >>>>> | UDP or TCP | >>>>> +---------------------------+ >>>>> >>>>> >>>>> I know it's kind of a step back from the tunnel protocol we've been >>>>> designing at so far, but it looks a lot cleaner, and allows for re-us= e of >>>>> already debugged components that will largely exist in implementation= s (or >>>>> that can be trivially sourced from commercially-friendly open source >>>>> projects). Overall -- and in addition to the other advantages -- I th= ink >>>>> this will be easier to specify and easier to implement. >>>>> >>>>> /a >>>>> >>>>> _______________________________________________ >>>>> Perc mailing list >>>>> >>>>> Perc@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/perc >>>>> >>>> _______________________________________________ >>>> Perc mailing list >>>> >>>> Perc@ietf.org >>>> https://www.ietf.org/mailman/listinfo/perc >>>> >>> > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > --001a11c0b166fc385e05391b89ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This may have been rais= ed and rebutted already, but have we considered WebSockets?=C2=A0 Yes, the = handshake and framing is a little clumsy, but it seems to meet the basic re= quirements here:

1. Reliable, secure transport
2. Mes= sage framing
3. Direct representation of both binary and text data=
4. Ability for either side to send messages at any time

With that, you could just say:

a. Any binary frame is a 4-= byte connection ID followed by a DTLS message
b. Any text frame MDD ->= ; KMF is a JSON message with capabilities
c. Any text frame KMF -> MD= D is a JSON message with keys

It seems like that would maximize the "just glue some librarie= s together and don't do any custom parsing" factor here.=C2=A0 You= r KMF-side tunnel implementation just glues a WebSocket libary to a JSON pa= rser and a DTLS stack, and the likewise on the MDD side.

=

On Tue, Aug 2, 2016 at 3:02 PM, Adam R= oach <adam@nostrum.com> wrote:
Like I said, I don't feel strongly about it. JSON would be my secon= d choice. It's verbose, but this is going to be a low-traffic interface= , so it doesn't bother me too much.

/a


On 8/2/16 14:00, Cullen Jennings wrote:
CBOR would be the worst of both worlds. Prefer the other approaches.

On Aug 1, 2016, at 2:37 PM, Adam Roach <adam@nostrum.com> wrote:

We had a discussion on this during the face-to-face in Berlin. The general = conclusion from that discussion was to go in the general direction that Cul= len outlines below: we create a single TLS/TCP connection from the KMF towa= rds the MDD. Over that connection, we use a simple encapsulation protocol t= hat allows us to exchange multiple flows of TLS traffic, along with some co= ntrol messages (supported ciphersuites, HBH keys).

This leaves us to decide the syntax for this framing (I fear this is kind o= f bikesheddy, but we need to nail it down). So far I've heard three bas= ic suggestions:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Hand-roll our own protocol, similar t= o what is currently in the tunnel draft.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Use JSON [RFC7159]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =E2=80=A2 Use CBOR [RFC7049]
Presumably, the JSON representation would look something like:

{
=C2=A0 =C2=A0"type": "tunnel",
=C2=A0 =C2=A0"channel": 4,
=C2=A0 =C2=A0"packet": "FgEAAAAAAAAAAAAAagEAAF4AAAAAAAAAXgEA= RI11KHx3QB6KyCKgoBj/kwjKrApkL8kiZ
=C2=A0 =C2=A0 =C2=A0LwIqBaJGT8AAAA2ADkAOAA1ABYAEwAKADMAMgAvAAcAZgAFAAQAYwBi= AGEAFQASAAkAZQ
=C2=A0 =C2=A0 =C2=A0BkAGAAFAARAAgABgADAQA=3D"
}
{
=C2=A0 =C2=A0"type": "profiles",
=C2=A0 =C2=A0"supported": [7,8]
}

{
=C2=A0 =C2=A0"type": "keys",
=C2=A0 =C2=A0"channel": 4,
=C2=A0 =C2=A0"profile": 8,
=C2=A0 =C2=A0"mki": 17,
=C2=A0 =C2=A0"server_key": "...",
=C2=A0 =C2=A0"server_salt": "...",
=C2=A0 =C2=A0"client_key": "...",
=C2=A0 =C2=A0"server_salt": "..."
}

(The "..." above are base-64 encoded values)

And the CBOR representation would simply encode these structures in CBOR, u= sing literal byte strings rather than base64 for the packets, keys, and sal= ts, and integers to encode packet types.

I have a slight preference for CBOR (it's more general than a custom sc= heme, and more compact than JSON), but nothing extremely strong.

/a

On 7/18/16 07:02, Cullen Jennings wrote:
So agree that snag kills the current plan.

Running a webrtc data channel looks like the most hideously complicated thi= ng we could do.=C2=A0 How about we just use a TLS connection made from the = KMF to the MDD? I don=E2=80=99t think the head of line issue or the putting= the MDD behind a NAT are practical enough use cases to justify the complex= ity.





On Jul 16, 2016, at 4:39 AM, Adam Roach <adam@nostrum.com>
=C2=A0 wrote:

Mozilla has started looking into implementation of a PERC KMF, and have run= into a bit of a snag with the tunnel protocol. Right now, the current tunn= el i-d plans on using the reliability of the underlying TLS handshake (clie= nt hello/server hello/finished/finished) to ensure that required informatio= n is exchanged between the KMF and the MDD.

Unfortunately, this won't work. The *reason* it won't work is that = TLS 1.3 (which we'll certainly want to support) performs a three-way ha= ndshake instead of a four-way handshake. So the message that we planned to = use to send the HBH key from the KMF to the MDD simply doesn't exist.
This means that we'll need some additional reliability mechanism.

We can roll our own -- but (as SIP taught us) that's not an awesome thi= ng to do -- or we can re-use something that already works. As we worked thr= ough how best to do this, something relatively simple presented itself. If = we use a stack similar to what we're using for WebRTC (SCTP/DTLS/ICE/UD= P), we can kill several birds with one stone:

* ICE gives us the keepalives we need to maintain NAT and firewall
=C2=A0 =C2=A0pinholes
* ICE provides a means for finding which of UDP or TCP will work
=C2=A0 =C2=A0through the firewall
* SCTP provides reliability for exchanging messages pertaining to
=C2=A0 =C2=A0supported ciphersuites and hop-by-hop keys
* SCTP provides multiple channels that can be used to carry multiple
=C2=A0 =C2=A0DTLS associations

Basically, this means we move away from a custom binary protocol for the tu= nnel and re-use existing designs. It's easier to specify, and (at least= , for the architectures we've been considering) much easier to implemen= t. It's worth noting that the MDD would only need to support ice-lite, = assuming it's deployed on a publicly-routable address.


+------+------+------+------+
| Ctrl | DTLS | DTLS | DTLS |=C2=A0 <- DTLS for DTLS-SRTP terminates her= e
+------+------+------+------+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SCTP=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 <- Provides control channel reliability, channel I= Ds
+---------------------------+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DTLS=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 |=C2=A0 <- DTLS here is the KMF <-> MDD connection +---------------------------+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ICE=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|=C2=A0 <- Provides keepalives, firewall traversal +---------------------------+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP or TCP=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<= br> +---------------------------+


I know it's kind of a step back from the tunnel protocol we've been= designing at so far, but it looks a lot cleaner, and allows for re-use of = already debugged components that will largely exist in implementations (or = that can be trivially sourced from commercially-friendly open source projec= ts). Overall -- and in addition to the other advantages -- I think this wil= l be easier to specify and easier to implement.

/a

_______________________________________________
Perc mailing list

Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc
_______________________________________________
Perc mailing list

Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc

--001a11c0b166fc385e05391b89ec-- From nobody Tue Aug 2 12:18:23 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A758812D8AB for ; Tue, 2 Aug 2016 12:18:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.187 X-Spam-Level: X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 xOF3HetxPCFW for ; Tue, 2 Aug 2016 12:18:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C2C8F12D855 for ; Tue, 2 Aug 2016 12:18:20 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u72JIJnd084473 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Aug 2016 14:18:20 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Richard Barnes References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> From: Adam Roach Message-ID: <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> Date: Tue, 2 Aug 2016 14:18:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:18:22 -0000 On 8/2/16 14:15, Richard Barnes wrote: > With that, you could just say: > > a. Any binary frame is a 4-byte connection ID followed by a DTLS message > b. Any text frame MDD -> KMF is a JSON message with capabilities > c. Any text frame KMF -> MDD is a JSON message with keys I think we want to be more extensible than this. While we currently only envision the need for one control message type in each direction, I don't want to have to tear the design up and start over if we discover more. /a From nobody Tue Aug 2 12:19:38 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB46512D8C1 for ; Tue, 2 Aug 2016 12:19:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 vV7zroOnNXRW for ; Tue, 2 Aug 2016 12:19:36 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 6D66A12D13E for ; Tue, 2 Aug 2016 12:19:36 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id j59so136374245uaj.3 for ; Tue, 02 Aug 2016 12:19:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=v67X0LNiyPu+SEMrhjmrdgNmC6yrRFftpaCD6XU0LMQ=; b=G7GFww4SuUYecXbR6vFZvKocyN9Oz/hIiHs8onMAV2i8BUDCk9njjFvo4SbLFZr8Fu h9h4RD7t+w7yBjl5yBh+MjPTo6PNDp4AQZSFxEQz2z+WRDVjbtbVYkMkGJmitvaV6kc6 SffTaQJfwWDRvHlC+uuqH+Qi7VElSBa1+l5lID92mM3PsvCP8nDjG75FgrIWh44MMnZ2 EwcI661ATVq30meoDOeY3gY0WGunqNSaHYMpdj5y4Vh/zvlHz5ba15wEwsDcnAPXBG/X nFWcSy0ioHYJeCKKYtnZ+nlkPeDhn5VVcuFGXzRHHFaX7QG3JJiXmXnOxcKDZRYjTFXn qRmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v67X0LNiyPu+SEMrhjmrdgNmC6yrRFftpaCD6XU0LMQ=; b=OKMICY3TZ3HaFBxMWGmz89kdvGgOqRj7/I7u4RLwfFk6cT+0JR2eVC56oL74Muql5q SrfTenI4T/Bs0QbrPzu5bG1vS76vz3C6nZQYfXLae+2JfLoREV+fOeinZc59/CElsvVx K9IKeZ6XXcNnE9p6dFuebl+C8Fty6xrZ8mH9vQmf9rm8Q3KQWEAEGJ6EgZJw7kBxaQk9 8SSQGLJeywMTa1dZwnEUZgbZpZ1qhHVO4IYr5E36KlYRolwohN5qMEfzxJKCcW6VhSJa qIVoAb87BTZ9onTbTouXZpBjBTvnwwXZ9d6W4XRBWjVLr+xP3u5Yb2m2tS+Al9aCGDem 0EUg== X-Gm-Message-State: AEkoouuCAbSD5hgHabAek84DHo15gP3zV9uPPEg0ajOhle17y+u87oUcD+BDUegL61357LebeEJQwPVPT7Brlg== X-Received: by 10.159.36.15 with SMTP id 15mr25806391uaq.79.1470165575513; Tue, 02 Aug 2016 12:19:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.49.212 with HTTP; Tue, 2 Aug 2016 12:19:34 -0700 (PDT) In-Reply-To: <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> From: Richard Barnes Date: Tue, 2 Aug 2016 15:19:34 -0400 Message-ID: To: Adam Roach Content-Type: multipart/alternative; boundary=001a113cd586e3ce1805391b989a Archived-At: Cc: "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 19:19:38 -0000 --001a113cd586e3ce1805391b989a Content-Type: text/plain; charset=UTF-8 Sure. { "type": "keys" } and so on. But it at least gives you a clear separation between the control channel and the DTLS, effectively for free. On Tue, Aug 2, 2016 at 3:18 PM, Adam Roach wrote: > On 8/2/16 14:15, Richard Barnes wrote: > >> With that, you could just say: >> >> a. Any binary frame is a 4-byte connection ID followed by a DTLS message >> b. Any text frame MDD -> KMF is a JSON message with capabilities >> c. Any text frame KMF -> MDD is a JSON message with keys >> > > > I think we want to be more extensible than this. While we currently only > envision the need for one control message type in each direction, I don't > want to have to tear the design up and start over if we discover more. > > > /a > > --001a113cd586e3ce1805391b989a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure. { "type": "keys" } and so on.=C2= =A0 But it at least gives you a clear separation between the control channe= l and the DTLS, effectively for free.
<= br>
On Tue, Aug 2, 2016 at 3:18 PM, Adam Roach <a= dam@nostrum.com> wrote:
On 8/2/16 14:15, Richard Barnes wrote:
With that, you could just say:

a. Any binary frame is a 4-byte connection ID followed by a DTLS message b. Any text frame MDD -> KMF is a JSON message with capabilities
c. Any text frame KMF -> MDD is a JSON message with keys


I think we want to be more extensible than this. While we currently only en= vision the need for one control message type in each direction, I don't= want to have to tear the design up and start over if we discover more.


/a


--001a113cd586e3ce1805391b989a-- From nobody Tue Aug 2 15:56:51 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0D6A12D9EB for ; Tue, 2 Aug 2016 15:56:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no 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 kFPYqpIJL6im for ; Tue, 2 Aug 2016 15:56:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 30A3E12D9E4 for ; Tue, 2 Aug 2016 15:56:47 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u72Mui29005452 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 2 Aug 2016 17:56:45 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Richard Barnes References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> From: Adam Roach Message-ID: <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> Date: Tue, 2 Aug 2016 17:56:44 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D2F49687E3F09FAC205EE91E" Archived-At: Cc: "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:56:49 -0000 This is a multi-part message in MIME format. --------------D2F49687E3F09FAC205EE91E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Okay, a few of us managed to get together on an ad hoc call today, and hashed out something that is much simpler than any of the proposals so far. It sheds the verbosity of JSON and Base64 encoding DTLS packets, avoids the need to add a CBOR parser to the system, and allows us to focus on the contents of our messages rather than hand-rolling a binary protocol. What we'd like to do is use the TLS presentation language to define binary structures that are then carried across the TLS connection between the KMF and MDD. Note that these are NOT new TLS messages; they're application data sent over TLS. The definition for what we have right now in the tunnel document would look something like: enum { invalid(0), supported_profiles(1), media_keys(2), tunneled_dtls(3), (255) } MsgType; struct { MsgType msg_type; select (MsgType) { case supported_profiles: SupportedProfiles; case media_keys: MediaKeys; case tunneled_dtls: TunneledDtls; } body; } TunnelMessage; // uint8 SRTPProtectionProfile[2]; // from RFC5764 struct { SRTPProtectionProfile suites<0..2^16-1>; } SupportedProfiles; struct { uint32 associationID; SRTPProtectionProfile profile; opaque mki<0..255>; opaque clientWriteKey<0..255>; opaque serverWriteKey<0..255>; opaque clientWriteSalt<0..255>; opaque serverWriteSalt<0..255>; } MediaKeys; struct { uint32 associationID; opaque dtlsMessage<0..2^16-1>; } TunneledDtls; [thanks to Richard and Cullen for working out the syntax here] If there are no objections, I believe one of our implementors will submit a PR in a short while to update the tunnel draft accordingly. /a --------------D2F49687E3F09FAC205EE91E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Okay, a few of us managed to get together on an ad hoc call today, and hashed out something that is much simpler than any of the proposals so far. It sheds the verbosity of JSON and Base64 encoding DTLS packets, avoids the need to add a CBOR parser to the system, and allows us to focus on the contents of our messages rather than hand-rolling a binary protocol.

What we'd like to do is use the TLS presentation language <https://tools.ietf.org/html/rfc5246#section-4> to define binary structures that are then carried across the TLS connection between the KMF and MDD. Note that these are NOT new TLS messages; they're application data sent over TLS.

The definition for what we have right now in the tunnel document would look something like:

enum {
  invalid(0),
  supported_profiles(1),
  media_keys(2),
  tunneled_dtls(3),
  (255)
} MsgType;

struct {
  MsgType msg_type;
  select (MsgType) {
    case supported_profiles: SupportedProfiles;
    case media_keys:         MediaKeys;
    case tunneled_dtls:      TunneledDtls;
  } body;
} TunnelMessage;

// uint8 SRTPProtectionProfile[2]; // from RFC5764

struct {
  SRTPProtectionProfile suites<0..2^16-1>;
} SupportedProfiles;

struct {
  uint32 associationID;
  SRTPProtectionProfile profile;
  opaque mki<0..255>;
  opaque clientWriteKey<0..255>;
  opaque serverWriteKey<0..255>;
  opaque clientWriteSalt<0..255>;
  opaque serverWriteSalt<0..255>;
} MediaKeys;

struct {
  uint32 associationID;
  opaque dtlsMessage<0..2^16-1>;
} TunneledDtls;


[thanks to Richard and Cullen for working out the syntax here]

If there are no objections, I believe one of our implementors will submit a PR in a short while to update the tunnel draft accordingly.

/a
--------------D2F49687E3F09FAC205EE91E-- From nobody Tue Aug 2 19:39:02 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0D1812D0FE for ; Tue, 2 Aug 2016 19:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 IZQe_R5htF0O for ; Tue, 2 Aug 2016 19:38:58 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B236112D5F4 for ; Tue, 2 Aug 2016 19:38:57 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u732ctVn026027 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 2 Aug 2016 22:38:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1470191936; bh=xBzUgrYnx7rlNM2TSHPLWfJFlEyNFvAklambMdih+mc=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=H32Z3/EIxMTp/sFPc5uaSZEIM2twbmmKA/Fz5iW9Qt7zMSGp803Sqv/WySvfP5m2Z WGNlEbGfJmFHbEE/LVMUEnBiZzCesXzDNS3auMR0/15K/AHtKYKlaCV0y0HoopEzA6 PlDxsNyUisekgAHx2aqF8BkHBNEuIPTZXhDz5vbI= From: "Paul E. Jones" To: "Adam Roach" , "Richard Barnes" Date: Wed, 03 Aug 2016 02:38:58 +0000 Message-Id: In-Reply-To: <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MBB1EAF4BE-80E4-4C06-81DC-F85E01D4E396" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Tue, 02 Aug 2016 22:38:56 -0400 (EDT) Archived-At: Cc: "perc@ietf.org" , Cullen Jennings Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 02:39:01 -0000 --------=_MBB1EAF4BE-80E4-4C06-81DC-F85E01D4E396 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Adam, Coming full circle... https://tools.ietf.org/html/draft-jones-perc-dtls-tunnel-00#section-6 Obviously, I like this form of syntax. And, we can insert comments to=20 add clarity ;-) In the original version, I had a "version" field. Do we want=20 versioning? I also placed the association ID before the select(). The association=20 ID has no meaning for supported profiles, but the value could be made=20 optional, e.g.: uint32 association_id<0..4> /* Optional Association Identifier */ Or, just have it as "uint32 association_id" and reserve the value 0 to=20 indicate absence. The reason for this is only to avoid duplicating that field in every=20 message type. I note that the keys and protection profiles are allowed to be absent=20 ("<0.." syntax). Is that really desired? Paul ------ Original Message ------ From: "Adam Roach" To: "Richard Barnes" Cc: "perc@ietf.org" ; "Cullen Jennings" Sent: 8/2/2016 6:56:44 PM Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach >Okay, a few of us managed to get together on an ad hoc call today, and=20 >hashed out something that is much simpler than any of the proposals so=20 >far. It sheds the verbosity of JSON and Base64 encoding DTLS packets,=20 >avoids the need to add a CBOR parser to the system, and allows us to=20 >focus on the contents of our messages rather than hand-rolling a binary= =20 >protocol. > >What we'd like to do is use the TLS presentation language=20 > to define binary=20 >structures that are then carried across the TLS connection between the=20 >KMF and MDD. Note that these are NOT new TLS messages; they're=20 >application data sent over TLS. > >The definition for what we have right now in the tunnel document would=20 >look something like: > >enum { > invalid(0), > supported_profiles(1), > media_keys(2), > tunneled_dtls(3), > (255) >} MsgType; > >struct { > MsgType msg_type; > select (MsgType) { > case supported_profiles: SupportedProfiles; > case media_keys: MediaKeys; > case tunneled_dtls: TunneledDtls; > } body; >} TunnelMessage; > >// uint8 SRTPProtectionProfile[2]; // from RFC5764 > >struct { > SRTPProtectionProfile suites<0..2^16-1>; >} SupportedProfiles; > >struct { > uint32 associationID; > SRTPProtectionProfile profile; > opaque mki<0..255>; > opaque clientWriteKey<0..255>; > opaque serverWriteKey<0..255>; > opaque clientWriteSalt<0..255>; > opaque serverWriteSalt<0..255>; >} MediaKeys; > >struct { > uint32 associationID; > opaque dtlsMessage<0..2^16-1>; >} TunneledDtls; > > >[thanks to Richard and Cullen for working out the syntax here] > >If there are no objections, I believe one of our implementors will=20 >submit a PR in a short while to update the tunnel draft accordingly. > >/a --------=_MBB1EAF4BE-80E4-4C06-81DC-F85E01D4E396 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable =20
Adam,

Coming full = circle...

Obviously,= I like this form of syntax.  And, we can insert comments to add clari= ty ;-)

In the original version, I had a "version"= field.  Do we want versioning?

I also placed= the association ID before the select().  The association ID has no= meaning for supported profiles, but the value could be made optional, e.g.= :

uint32 association_id<0..4> /* Optional= Association Identifier */

Or, just have it as = "uint32 association_id" and reserve the value 0 to indicate absence.  =

The reason for this is only to avoid duplicating= that field in every message type.

I note that = the keys and protection profiles are allowed to be absent ("<0.." syntax= ).  Is that really desired?

Paul
------ Original Message ------
From: "Adam Roach" <adam@nostru= m.com>
To: "Richard Barnes" <rlb@ipv.sx&= gt;
Cc: "perc@ietf.org" <perc@ietf.org= >; "Cullen Jennings" <fluffy@iii= .ca>
Sent: 8/2/2016 6:56:44 PM
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

Okay, a few of us managed to get together on an ad hoc call today, and hashed out something that is much simpler than any of the proposals so far. It sheds the verbosity of JSON and Base64 encoding DTLS packets, avoids the need to add a CBOR parser to the system, and allows us to focus on the contents of our messages rather than hand-rolling a binary protocol.

What we'd like to do is use the TLS presentation language <https://tools.ietf.org/html/rfc5246#section-4><= /a> to define binary structures that are then carried across the TLS connection between the KMF and MDD. Note that these are NOT new TLS messages; they're application data sent over TLS.

The definition for what we have right now in the tunnel document would look something like:

=20
enum {
  invalid(0),
  supported_profiles(1),
  media_keys(2),
  tunneled_dtls(3),
  (255)
} MsgType;

struct {
  MsgType msg_type;
  select (MsgType) {
    case supported_profiles: SupportedProfiles;
    case media_keys:        = MediaKeys;
    case tunneled_dtls:      TunneledDtls;
  } body;
} TunnelMessage;

// uint8 SRTPProtectionProfile[2]; // from RFC5764

struct {
  SRTPProtectionProfile suites<0..2^16-1>;
} SupportedProfiles;

struct {
  uint32 associationID;
  SRTPProtectionProfile profile;
  opaque mki<0..255>;
  opaque clientWriteKey<0..255>;
  opaque serverWriteKey<0..255>;
  opaque clientWriteSalt<0..255>;
  opaque serverWriteSalt<0..255>;
} MediaKeys;

struct {
  uint32 associationID;
  opaque dtlsMessage<0..2^16-1>;
} TunneledDtls;


[thanks to Richard and Cullen for working out the syntax here]
If there are no objections, I believe one of our implementors will submit a PR in a short while to update the tunnel draft accordingly.

/a
--------=_MBB1EAF4BE-80E4-4C06-81DC-F85E01D4E396-- From nobody Wed Aug 3 14:52:42 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ADF12D6A7 for ; Wed, 3 Aug 2016 14:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vRtQz_z3_V8X for ; Wed, 3 Aug 2016 14:52:38 -0700 (PDT) Received: from smtp149.dfw.emailsrvr.com (smtp149.dfw.emailsrvr.com [67.192.241.149]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C48A12D580 for ; Wed, 3 Aug 2016 14:52:38 -0700 (PDT) Received: from smtp11.relay.dfw1a.emailsrvr.com (localhost [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8420CC0216; Wed, 3 Aug 2016 17:52:37 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 0A686C021F; Wed, 3 Aug 2016 17:52:36 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 03 Aug 2016 17:52:37 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 3 Aug 2016 15:52:36 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> To: Paul Jones X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 21:52:40 -0000 > On Aug 2, 2016, at 8:38 PM, Paul E. Jones = wrote: >=20 >=20 > In the original version, I had a "version" field. Do we want = versioning? >=20 >=20 At some level, we get versioning by being able to add new messages to = the MsgType enum. We could also add an explicit version field. I'm fine = either way.=20 From nobody Wed Aug 3 15:16:48 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4C5412D737 for ; Wed, 3 Aug 2016 15:16:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 c_uDTSYll1yE for ; Wed, 3 Aug 2016 15:16:44 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D892612D674 for ; Wed, 3 Aug 2016 15:16:44 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-215.nc.res.rr.com [98.122.181.215] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u73MGcF6016364 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Aug 2016 18:16:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1470262603; bh=KpR3ARbf9BQTkRhF2uGg9KaUapNY5yhqAvLaok1Pk4s=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=JHZPxQMpabJAcU/CURrLqaYGvX/O2dtnWRrfOwHGV65MYmcyOaEifv6JrIQuEBHhp HYoGTGb0EGuydoGY01oLi5TnbJdsYB4GTACHBZXgI7SxyW093ysKmFOtHpMWE7JO1b w6Ay73LK0HQigMxbF81fYndJj52n655W3QioX464= From: "Paul E. Jones" To: "Cullen Jennings" Date: Wed, 03 Aug 2016 22:16:42 +0000 Message-Id: In-Reply-To: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Wed, 03 Aug 2016 18:16:43 -0400 (EDT) Archived-At: Cc: Richard Barnes , Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 22:16:46 -0000 If we want to add new data elements to existing messages, we'd need to=20 version the protocol since a receiver would otherwise barf on the=20 received message. We could easily get by with a single version octet (versus the two=20 octets I had in the -00 draft). I would prefer we introduce a single=20 "uint8 protocol_version" element to ensure we have a means of gracefully= =20 handling version misalignment. Paul ------ Original Message ------ From: "Cullen Jennings" To: "Paul Jones" Cc: "Adam Roach" ; "Richard Barnes" ;=20 "perc@ietf.org" Sent: 8/3/2016 5:52:36 PM Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach > >> On Aug 2, 2016, at 8:38 PM, Paul E. Jones =20 >>wrote: >> >> >> In the original version, I had a "version" field. Do we want=20 >>versioning? >> >> > >At some level, we get versioning by being able to add new messages to=20 >the MsgType enum. We could also add an explicit version field. I'm fine= =20 >either way. > > > From nobody Wed Aug 3 17:20:52 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1398E12D500 for ; Wed, 3 Aug 2016 17:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 5lRlJqKH4aMD for ; Wed, 3 Aug 2016 17:20:48 -0700 (PDT) Received: from smtp85.ord1c.emailsrvr.com (smtp85.ord1c.emailsrvr.com [108.166.43.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1E8D12D1A6 for ; Wed, 3 Aug 2016 17:20:48 -0700 (PDT) Received: from smtp19.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 0C686A01AE; Wed, 3 Aug 2016 20:20:43 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6BA13A0178; Wed, 3 Aug 2016 20:20:42 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.185]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 03 Aug 2016 20:20:43 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Cullen Jennings In-Reply-To: Date: Wed, 3 Aug 2016 18:20:41 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7631c2d0-4fec-4b47-04f5-aa8354e44ca2@nostrum.com> <30B5068D-4790-4043-AD89-0C2764BE2531@iii.ca> <9e3380dd-3667-97a4-c456-175404efb454@nostrum.com> <3D620FA2-60D4-4286-938E-97447B02B755@iii.ca> <4b62ee1d-2cbd-d951-7a1d-389288ff4719@nostrum.com> <099913b7-074c-13e6-9bb5-a40ee9427db9@nostrum.com> <2f7bdbb1-a1aa-e0f1-99af-b433f3045027@nostrum.com> To: Paul Jones X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Richard Barnes , Adam Roach , "perc@ietf.org" Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 00:20:50 -0000 > On Aug 3, 2016, at 4:16 PM, Paul E. Jones = wrote: >=20 > We could easily get by with a single version octet (versus the two = octets I had in the -00 draft). I would prefer we introduce a single = "uint8 protocol_version" element to ensure we have a means of gracefully = handling version misalignment. sounds good to me From nobody Thu Aug 18 14:38:27 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 389D412D56F for ; Thu, 18 Aug 2016 14:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 ZILpdGW3l1uU for ; Thu, 18 Aug 2016 14:38:24 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 285AE12B01F for ; Thu, 18 Aug 2016 14:38:23 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id 74so50309736uau.0 for ; Thu, 18 Aug 2016 14:38:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=yEk9UWK3FvzuylIqVSZG/K0mcJGUqM6XjrGkXBfGD4g=; b=ffoSs/NVttyff7QDXfnFLWZpSG2b35Vw61iYCV5S+ysyrUDoXesj2+k4OwZUU/CoX0 uMMJaX2OZKW6UhrfSzjaSBa3EybnKppbNGlYsevq9mG/dCLd/MX1WMOda83tRI1n0LQw Nh9aoPP4y4tUCmjBcIR7/qumqAca9/E5Rsn0s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yEk9UWK3FvzuylIqVSZG/K0mcJGUqM6XjrGkXBfGD4g=; b=l2tTcUv0yWEFJqagx3kuGI70Mvl8RU2hr7rGZh8RpywwR1JA6AZyRSSZWBf5kdBC18 fF7r7qvpweB81smviXyOSepkWhLdo0RrSG0BheeIhAuc8Okhcd/Q3ZqNS30T7x0ScKdP yGo8BZpoC0rslddHPBdl2cVe4Rk0mpR3aZy2by8I0yOBDEPCkEOY1JgDyktwOgea3Kmp GzUmqPUz4GCh0XaGtxx+L2ZGNksxT1CN0sywouhhOFYW/lEy3CpB4GpziniE5cbE6pw7 GwZGIlDXsGMLcN/ZsuixiAiFMpMVAHpAG1Uyde5ZpER7z52wGTsYPPZBK+gkZHG8FQxy /BvA== X-Gm-Message-State: AEkooutpNRCggmi/P5eTAa0l3x+DRZ0OAPtVWUjKwHg2LpVsgji8b5Q8epikkytMrGUL0Mn43xcUIyCjH39q4NPl X-Received: by 10.31.49.7 with SMTP id x7mr2321027vkx.158.1471556303008; Thu, 18 Aug 2016 14:38:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.77 with HTTP; Thu, 18 Aug 2016 14:38:22 -0700 (PDT) From: Paul Ellenbogen Date: Thu, 18 Aug 2016 14:38:22 -0700 Message-ID: To: perc@ietf.org Content-Type: multipart/alternative; boundary=001a114407d8b566bd053a5f6683 Archived-At: Subject: [Perc] MD notifying KD of client exit X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 21:38:26 -0000 --001a114407d8b566bd053a5f6683 Content-Type: text/plain; charset=UTF-8 Although I believe a call participant can close the DTLS association, if the client does not exit gracefully the KD may never know. The MD is in a better position to know if this is the case because the client's stream of SRTP packets to the MD will stop. If we want to re-key the conference whenever a client leaves, there should be a message from the MD to the KD when the MD detects a participant drops out of the call. Thoughts? Paul Ellenbogen --001a114407d8b566bd053a5f6683 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Although I believe a call participant can close the D= TLS association, if the client does not exit gracefully the KD may never kn= ow. The MD is in a better position to know if this is the case because the = client's stream of SRTP packets to the MD will stop. If we want to re-k= ey the conference whenever a client leaves, there should be a message from = the MD to the KD when the MD detects a participant drops out of the call.
Thoughts?

Paul Ellenbogen
--001a114407d8b566bd053a5f6683-- From nobody Thu Aug 18 14:43:52 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1033612D0BF for ; Thu, 18 Aug 2016 14:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 pfttHSK06q4T for ; Thu, 18 Aug 2016 14:43:49 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 D090B12B02F for ; Thu, 18 Aug 2016 14:43:48 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 97so50244394uav.3 for ; Thu, 18 Aug 2016 14:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=889YUAw965Jq9xeukbGWU1dAQZlssrCFgSdXLc6PDWA=; b=1X3YYdJ6GpWzs9HM5E7cCFa+oF42LDUx6CtmJF9+5J4wraZFosDST+4F2krbMwamM9 JH3LheST14U2vrO1FxWzeUi8UHqI/aeA8EpZyF7lDX86rq5q8VggKyXzyxTT5hupMmJh A+0BtyCS2cqCfeoiQrLCjSCj2OrWs25+kumab2wIjPrFgjGV8zFs+PCvqmGD3tnJjgr3 hbhd0OyOpnIwR02Xtw/NTfiVKVZqDrsOzN0TpMmWRcIO4jF7yhjPEVNNx/0HhcWjkcV7 NdQ1jEjsImtlevaz6UsdkOj7peRs7lBU7bEgf0542U5pSvWmMqfSYdMSkljt1CVilG3Q e5xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=889YUAw965Jq9xeukbGWU1dAQZlssrCFgSdXLc6PDWA=; b=gzvGbBJQD5lTRgjkfeVPOiHktwJ0ukGgpmoo2+OHvodzY+nyYsGrEVsdQUqSqDFAWJ iQ/HFCYVL9erHSjWcglO00XxsbeE+H8UtUQYscAuHUA7WS7JzJkausWbExpUn8k82962 gDCH4NYINDx0Vg7TpUTFXO5ErDkKd4ol9G34B36mkUtv0A/dSs9vHnxATMnJF0dRBjgc M2PSLISZfG9oc782dOF67UbfDjgkZ2H+b/3XSEar5owZFBKe60zO6R1Qtet2D7JHJcyf R8Jg5xm8hCaPLCY0h0iZ9fVdo4wowOLRvLPLo/pDkDa3QStv0XQ5Y8Zr0+YHC1MyD/J6 v9QQ== X-Gm-Message-State: AEkoout4tsL7Dc62ZqZBnDk7ZvBNiS3ZKS+KytjBxSH+1GpdkTZ8zJfGGqRTOySOOCCGktK5hJ5U8sJF4M6nmQ== X-Received: by 10.159.36.108 with SMTP id 99mr1891739uaq.79.1471556627900; Thu, 18 Aug 2016 14:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.49.212 with HTTP; Thu, 18 Aug 2016 14:43:47 -0700 (PDT) In-Reply-To: References: From: Richard Barnes Date: Thu, 18 Aug 2016 17:43:47 -0400 Message-ID: To: Paul Ellenbogen Content-Type: multipart/alternative; boundary=001a113d126812bf2e053a5f7a47 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] MD notifying KD of client exit X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 21:43:51 -0000 --001a113d126812bf2e053a5f7a47 Content-Type: text/plain; charset=UTF-8 Seems sensible. You would just want to have another MD->KD message that says "$ASSOC_ID dropped"? On Thu, Aug 18, 2016 at 5:38 PM, Paul Ellenbogen wrote: > Although I believe a call participant can close the DTLS association, if > the client does not exit gracefully the KD may never know. The MD is in a > better position to know if this is the case because the client's stream of > SRTP packets to the MD will stop. If we want to re-key the conference > whenever a client leaves, there should be a message from the MD to the KD > when the MD detects a participant drops out of the call. > > Thoughts? > > Paul Ellenbogen > > _______________________________________________ > Perc mailing list > Perc@ietf.org > https://www.ietf.org/mailman/listinfo/perc > > --001a113d126812bf2e053a5f7a47 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Seems sensible.=C2=A0 You would just want to have another = MD->KD message that says "$ASSOC_ID dropped"?

On Thu, Aug 18, 2016 at = 5:38 PM, Paul Ellenbogen <pellenbogen@mozilla.com> wro= te:
Although I beli= eve a call participant can close the DTLS association, if the client does n= ot exit gracefully the KD may never know. The MD is in a better position to= know if this is the case because the client's stream of SRTP packets t= o the MD will stop. If we want to re-key the conference whenever a client l= eaves, there should be a message from the MD to the KD when the MD detects = a participant drops out of the call.

Thoughts?

Paul Ellenbogen

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc


--001a113d126812bf2e053a5f7a47-- From nobody Thu Aug 18 14:59:15 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DD312D0B6 for ; Thu, 18 Aug 2016 14:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.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 3yXReXu1L5QU for ; Thu, 18 Aug 2016 14:59:08 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 0D67012D689 for ; Thu, 18 Aug 2016 14:59:08 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 97so50782977uav.3 for ; Thu, 18 Aug 2016 14:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5IemhaXMcIziDYx9FE610aFxRoV1lwMKi+VnxCZEIiY=; b=Rv0OnAi6bPy6C+4uSOnpHbQT4F1BRzrtCSlMo4n/FcjABPYhs3A42wUjoBA2i9meTL DA43cdVyty4b3s2tqHH1Im30bYia+Rfzmtn/jeBWfOOLH2V32RPf2OgxrXdGUImI5FaR 0SnJmgk/8PKvTtYYb68VgyPkKzisjxUgz5fjo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5IemhaXMcIziDYx9FE610aFxRoV1lwMKi+VnxCZEIiY=; b=NACqM3pF84aKTdMpw9SGtK2T3nW6ADrcpo/NFZdpvwnOv8NS28Tpki4tF8X2B60yHR U7J7q4hFF0ta4KLTNc1bqjrp0kf+O0gNTRc/2dqcAVMTj6xgZqqQ3URZB4uG1QELLEO7 GpRlaFUFnPD5RGGnSnV4Eyshxql9goR5ym+1BG35mo4uZZBolg5Qw5gyhxx97y4+j1uD C8ogWAlXSDSYgmvNmxvNTqbDEfy+bO9wZf/fg6QQQcShWLNMhBs6FwYth59YuKZ56G5H 3FqbfRlBjQv3XD2hYxq70YkO66qqSVzj92NUOyi3Lt2/lJdTrJRcuvW6R5ulHFMIrH9c A8OA== X-Gm-Message-State: AEkoouvToAonX27vgxdEvXkLw9HtepnAX/5/lIYfrXCn3BF9KtWWUKRofVK8zvrxkBPy6YvrLokZvOE6mJWk74ZE X-Received: by 10.31.5.213 with SMTP id 204mr2002974vkf.60.1471557547095; Thu, 18 Aug 2016 14:59:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.3.77 with HTTP; Thu, 18 Aug 2016 14:59:06 -0700 (PDT) In-Reply-To: References: From: Paul Ellenbogen Date: Thu, 18 Aug 2016 14:59:06 -0700 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=001a1143f26cdc9088053a5fb087 Archived-At: Cc: perc@ietf.org Subject: Re: [Perc] MD notifying KD of client exit X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 21:59:15 -0000 --001a1143f26cdc9088053a5fb087 Content-Type: text/plain; charset=UTF-8 I see two possible approaches. One is what you suggest where you have status message type. The status message would have association id and the status, which in this case is dropped. This allows statuses to be added later. Alternatively we have a "Dropped" message type that just has the association ID of the dropped client. I don't feel strongly about either. On Thu, Aug 18, 2016 at 2:43 PM, Richard Barnes wrote: > Seems sensible. You would just want to have another MD->KD message that > says "$ASSOC_ID dropped"? > > On Thu, Aug 18, 2016 at 5:38 PM, Paul Ellenbogen > wrote: > >> Although I believe a call participant can close the DTLS association, if >> the client does not exit gracefully the KD may never know. The MD is in a >> better position to know if this is the case because the client's stream of >> SRTP packets to the MD will stop. If we want to re-key the conference >> whenever a client leaves, there should be a message from the MD to the KD >> when the MD detects a participant drops out of the call. >> >> Thoughts? >> >> Paul Ellenbogen >> >> _______________________________________________ >> Perc mailing list >> Perc@ietf.org >> https://www.ietf.org/mailman/listinfo/perc >> >> > --001a1143f26cdc9088053a5fb087 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I see two possible approaches.

One is what you= suggest where you have status message type. The status message would have = association id and the status, which in this case is dropped. This allows s= tatuses to be added later.

Alternatively we have a "Dropped&quo= t; message type that just has the association ID of the dropped client.
=
I don't feel strongly about either.

On Thu, Aug 18, 2016 at 2:43 PM, = Richard Barnes <rlb@ipv.sx> wrote:
Seems sensible.=C2=A0 You would just want to have anot= her MD->KD message that says "$ASSOC_ID dropped"?

On Thu, Aug 18, 2016 at 5:38 PM, Paul Ellenbogen <<= a href=3D"mailto:pellenbogen@mozilla.com" target=3D"_blank">pellenbogen@moz= illa.com> wrote:
Although I believe a call pa= rticipant can close the DTLS association, if the client does not exit grace= fully the KD may never know. The MD is in a better position to know if this= is the case because the client's stream of SRTP packets to the MD will= stop. If we want to re-key the conference whenever a client leaves, there = should be a message from the MD to the KD when the MD detects a participant= drops out of the call.

Thoughts?

= Paul Ellenbogen

_______________________________________________
Perc mailing list
Perc@ietf.org
https://www.ietf.org/mailman/listinfo/perc



--001a1143f26cdc9088053a5fb087-- From nobody Thu Aug 18 16:33:09 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8FC12D5BF for ; Thu, 18 Aug 2016 16:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 Epuu4RisODpp for ; Thu, 18 Aug 2016 16:33:05 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7827612D5A9 for ; Thu, 18 Aug 2016 16:33:05 -0700 (PDT) Received: from [192.168.1.20] (cpe-098-122-181-220.nc.res.rr.com [98.122.181.220] (may be forged)) (authenticated bits=0) by dublin.packetizer.com (8.15.2/8.15.2) with ESMTPSA id u7INX3io032672 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Aug 2016 19:33:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1471563184; bh=xXTsHsssO3ylhxz2bVmM6jVcNvDtzYYOda04nG9Ty8c=; h=From:To:Subject:Date:In-Reply-To:References:Reply-To; b=N7NLHeDInmGck4TF1H+rW5cGG4emvBM0bh1+IiYerKPMbffEhlgbPWITnB3jsjC6u YxAc2I0+XiHp9tKs45l42rYHuCYyAT3cZp8fGjs7mFybq9pM84Hhwyr4K/pdjhnNII OmQKwHETPhHcijyUwJ4RPMBSq1uGYvgnlEyxSPRU= From: "Paul E. Jones" To: "Paul Ellenbogen" , perc@ietf.org Date: Thu, 18 Aug 2016 23:33:05 +0000 Message-Id: In-Reply-To: References: User-Agent: eM_Client/7.0.26482.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB69B84712-1657-4485-A85E-29416DC22581" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6 (dublin.packetizer.com [10.137.60.122]); Thu, 18 Aug 2016 19:33:04 -0400 (EDT) Archived-At: Subject: Re: [Perc] MD notifying KD of client exit X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "Paul E. Jones" List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 23:33:07 -0000 --------=_MB69B84712-1657-4485-A85E-29416DC22581 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Paul, This would be reasonable to do so long as we can ensure that some=20 packets are sent from the client to the server on a regular basis that=20 the server can authenticate. Usually, there is some kind of traffic=20 (voice, video, or STUN) quite frequently. In the past with voice-only=20 calls, I've seen some devices literally stop sending audio packets when=20 the user hit the mute button. There should at least "silence" frames,=20 instead. Just so there is no doubt, should we have something written that says an= =20 endpoint must send either a media or STUN packet ever N seconds to=20 ensure that the the Media Distributor recognizes that the endpoint is=20 still present. Likewise, It must not be a packet that can be replayed. =20 All RTP and RTCP packets work for that. It could be STUN, but I'll=20 venture to guess that I could replay those to a Media Distributor and it= =20 would not be the wiser. A NONCE attribute could be inserted, but=20 keeping up with what values have and have not been used would be a pain.= =20 Perhaps you can think of a better solution, but I'd prefer to just=20 mandate an RTP or RTCP packet at least every N seconds. No reason that=20 cannot happen. There are other points of failure that can be equally problematic for=20 secure deployments where re-keying is needed if a person leaves the=20 conference. For example, if the Key Distributor failed, then it would be= =20 impossible to re-key the conference. If the "conference controller"=20 (whatever is directing the media distributor to allocate ports / process= =20 SDP / whatever) fails, that could also be a problem. Perhaps for this=20 limited class of conferences, we might also specify that the conference=20 should be torn down if either the Key Distributor or conference=20 controller become unresponsive. We could introduce an application level "ping" for the tunnel interface=20 to be used when the conference is active, but there are no other=20 messages traversing the tunnel. Since we are not defining the protocol that communicates with the Media=20 Distributor to allocate ports, perhaps we put something in the framework= =20 that speaks to it. That's a problem outside the scope of the WG. Paul ------ Original Message ------ From: "Paul Ellenbogen" To: perc@ietf.org Sent: 8/18/2016 5:38:22 PM Subject: [Perc] MD notifying KD of client exit >Although I believe a call participant can close the DTLS association,=20 >if the client does not exit gracefully the KD may never know. The MD is= =20 >in a better position to know if this is the case because the client's=20 >stream of SRTP packets to the MD will stop. If we want to re-key the=20 >conference whenever a client leaves, there should be a message from the= =20 >MD to the KD when the MD detects a participant drops out of the call. > >Thoughts? > >Paul Ellenbogen --------=_MB69B84712-1657-4485-A85E-29416DC22581 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Paul,

Th= is would be reasonable to do so long as we can ensure that some packets = are sent from the client to the server on a regular basis that the server= can authenticate.  Usually, there is some kind of traffic (voice, = video, or STUN) quite frequently.  In the past with voice-only calls,= I've seen some devices literally stop sending audio packets when the user= hit the mute button.  There should at least "silence" frames, instead= .

Just so there is no doubt, should we have someth= ing written that says an endpoint must send either a media or STUN packet= ever N seconds to ensure that the the Media Distributor recognizes that= the endpoint is still present. Likewise, It must not be a packet that can= be replayed.  All RTP and RTCP packets work for that.  It could= be STUN, but I'll venture to guess that I could replay those to a Media= Distributor and it would not be the wiser.  A NONCE attribute could= be inserted, but keeping up with what values have and have not been used= would be a pain.  Perhaps you can think of a better solution, but = I'd prefer to just mandate an RTP or RTCP packet at least every N seconds.=  No reason that cannot happen.

There are = other points of failure that can be equally problematic for secure deployme= nts where re-keying is needed if a person leaves the conference. For exampl= e, if the Key Distributor failed, then it would be impossible to re-key = the conference.  If the "conference controller" (whatever is directing= the media distributor to allocate ports / process SDP / whatever) fails,= that could also be a problem.  Perhaps for this limited class of conf= erences, we might also specify that the conference should be torn down if= either the Key Distributor or conference controller become unresponsive.

We could introduce an application level "ping" for= the tunnel interface to be used when the conference is active, but there= are no other messages traversing the tunnel.

Sinc= e we are not defining the protocol that communicates with the Media Distrib= utor to allocate ports, perhaps we put something in the framework that spea= ks to it.  That's a problem outside the scope of the WG.
Paul

------ Original Message ------
From: "Paul Ellenbogen" <pellenbogen@mozilla.com>
Sent: 8/18/2016 5:38:22 PM
Subject: [Perc] MD notifying KD of client exit

Although I believe a call participant can close the= DTLS association, if the client does not exit gracefully the KD may never= know. The MD is in a better position to know if this is the case because= the client's stream of SRTP packets to the MD will stop. If we want to = re-key the conference whenever a client leaves, there should be a message= from the MD to the KD when the MD detects a participant drops out of the= call.

Thoughts?

Paul Ellenbogen<= br>
--------=_MB69B84712-1657-4485-A85E-29416DC22581-- From nobody Thu Aug 18 16:45:27 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8355D12D1BD for ; Thu, 18 Aug 2016 16:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no 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 IJjrZAw3nKrG for ; Thu, 18 Aug 2016 16:45:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 5212C12D5A9 for ; Thu, 18 Aug 2016 16:45:23 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7INjLPk038008 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 18 Aug 2016 18:45:22 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "Paul E. Jones" , Paul Ellenbogen , perc@ietf.org References: From: Adam Roach Message-ID: <4940efb1-07dc-d8ff-afb3-f8a8b7207033@nostrum.com> Date: Thu, 18 Aug 2016 18:45:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Perc] MD notifying KD of client exit X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 23:45:25 -0000 On 8/18/16 18:33, Paul E. Jones wrote: > This would be reasonable to do so long as we can ensure that some > packets are sent from the client to the server on a regular basis that > the server can authenticate. Usually, there is some kind of traffic > (voice, video, or STUN) quite frequently. In the past with voice-only > calls, I've seen some devices literally stop sending audio packets > when the user hit the mute button. I'm okay reiterating in the PERC documents that RTCP is not, and has never been, optional. /a From nobody Fri Aug 19 10:17:17 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED312D60D; Fri, 19 Aug 2016 10:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147162703528.24145.2248265044941269033.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 10:17:15 -0700 Archived-At: Cc: perc-chairs@ietf.org, ben@nostrum.com, snandaku@cisco.com, perc@ietf.org Subject: [Perc] perc - New Meeting Session Request for IETF 97 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 17:17:15 -0000 A new meeting session request has just been submitted by Suhas Nandakumar, a Chair of the perc working group. --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb tls avtcore avtext clue siprec netvc acme lurk Second Priority: tcpinc oauth jose straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten Special Requests: added modern and saag as conflicts per Ben and Alissa --------------------------------------------------------- From nobody Fri Aug 19 11:18:16 2016 Return-Path: X-Original-To: perc@ietf.org Delivered-To: perc@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5E712D91F; Fri, 19 Aug 2016 11:18:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147163069541.24226.12620935276972239410.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 11:18:15 -0700 Archived-At: Cc: perc-chairs@ietf.org, ben@nostrum.com, snandaku@cisco.com, perc@ietf.org Subject: [Perc] perc - Update to a Meeting Session Request for IETF 97 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:18:15 -0000 An update to a meeting session request has just been submitted by Suhas Nandakumar, a Chair of the perc working group. --------------------------------------------------------- Working Group Name: Privacy Enhanced RTP Conferencing Area Name: Applications and Real-Time Area Session Requester: Suhas Nandakumar Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: rtcweb tls avtcore avtext clue siprec netvc acme lurk sipbrandy Second Priority: tcpinc oauth jose straw sipcore stir payload xrblock uta mmusic modern saag Third Priority: stox codec dispatch insipid p2psip kitten Special Requests: added modern and saag as conflicts per Ben and Alissa --------------------------------------------------------- From nobody Fri Aug 26 07:54:02 2016 Return-Path: X-Original-To: perc@ietfa.amsl.com Delivered-To: perc@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A817A12D0A3 for ; Fri, 26 Aug 2016 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 796DJzTlD-CZ for ; Fri, 26 Aug 2016 07:53:59 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BAC12D0C7 for ; Fri, 26 Aug 2016 07:53:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D09B2300499 for ; Fri, 26 Aug 2016 10:53:55 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rC3djpE9WB3U for ; Fri, 26 Aug 2016 10:53:54 -0400 (EDT) Received: from [192.168.2.100] (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) by mail.smeinc.net (Postfix) with ESMTPSA id 579B630040F for ; Fri, 26 Aug 2016 10:53:54 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 26 Aug 2016 10:54:02 -0400 To: perc@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [Perc] Review of draft-ietf-perc-srtp-ekt-diet-01 X-BeenThere: perc@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Privacy Enhanced RTP Conferencing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 14:54:01 -0000 In Berlin, I agreed to d a review of draft-ietf-perc-srtp-ekt-diet-01 by = the end of August. Here is my review. I have sent a more complete review to the authors. I have included = editorial comments in the review sent to the authors. I stick to = technical comments in this posting. Figure 1 is incomplete. I think that the =932=94 in the right margin is = supposed to represent the EKT_Msg_Type_Full. Section 2.1 says: EKT_Ciphertext: The data that is output from the EKT encryption operation, described in Section 2.3. This field is included in SRTP packets when EKT is in use. The length of this field is variable, and is equal to the ciphertext size N defined in Section 2.3. Note that the length of the field is inferable from the SPI field, since the SPI will indicate the cipher being used and thus the size. This is not correct! Two things neet to be known to figure out the = length. First, the cipher being used to encrypt the EKT_Plaintext, and = second the size of the SRTP master key. RFC 3771 says that the master = key can be 128, 192, or 256 bits. I think that the SPI only tells one = of these. Section 2.1 says: Time to Live (TTL): The maximum amount of time that this key can be used. A unsigned 16 bit integer representing duration in seconds. The SRTP Master key in this message MUST NOT be used for encrypting or decrypting information after this time. Open Issue: does this need to be absolute time not duration? TODO: discuss in security section. If a new participant joins, do they need to know when the start time for = the TTL. This might not be a problem is the sender is the only party = doing the enforcement. If a recipient is expected to discard any = traffic after the TTL expires, then the recipient will need to know the = absolute time as well as the TTL. Section 2.1 says: Security Parameter Index (SPI): This field indicates the appropriate EKT Key and other parameters for the receiver to use when processing the packet. Each time a different EKT Key is received, it will have a larger SPI than the previous key (after taking rollover into account). The length of this field is 16 bits. The parameters identified by this field are: I am confused here. I thought the SPI identified the cipher, key, and = associated parameters needed to decrypt the EKT_Ciphertext. Two = different SRTP sources can use the same SPI value, and the will identify = two different keys. Why does the SPI value monotonically increase? Since it is assigned by = the SRTP source, we have no idea when any given participant will see it = for a long-lived conference. Section 2.2 says: All SRTP master keys MUST NOT be re-used, MUST be randomly generated according to [RFC4086], and MUST NOT be equal to or derived from other SRTP master keys. You do not really want people to write code to check that the randomly = generated makter key does not match a previously generated master key. = I suggest: SRTP master keys MUST be randomly generated, and [RFC4086] offers some guidance about random number generation. SRTP master keys MUST NOT be re-used for any other purpose, and SRTP master keys MUST NOT be derived from other SRTP master keys. That said, this text is out of place. It does not belong in the = discussion of packet processing and the state machine. Section 2.2.2 says: Inbound EKT processing MUST take place prior to the usual SRTP or SRTCP processing. The following steps show processing as packets are received in order. Will an implementation ever be doing SRTP with EKT with some sessions = and SRTP without EKT for other sessions at the same time? If so, how = does the inbound processing determine whether an EKT is present or not? Section 2.3.1 says: The default EKT Cipher is the Advanced Encryption Standard (AES) Key Wrap with Padding [RFC5649] algorithm. It requires a plaintext length M that is at least one octet, and it returns a ciphertext with a length of N =3D M + 8 octets. =20 This only true if len(M) is a multiple of 64 bits. Both examples in = Section 6 of RFC 5649 show cases where this equation is incorrect. = Figure 4 also shows that this equation is incorrect. The equation should be: N =3D M + (M mod 8) + 8 Section 2.1 does not agree with Figure 4. Section 2.1 says that the = length field and the following message type are counted. The values in = Figure 4 only accommodates the SPI of 2 octets. Section 2.3.2 says: Other specifications may extend this one by defining other EKT ciphers per Section 7. This section defines how those ciphers interact with this specification. Section 7 does not tell how to register more EKT ciphers. Section 2.6 says: Rekey: By sending EKT over SRTP, the rekeying event shares fate with the SRTP packets protected with that new SRTP master key. Yes, but packet loss is possible here too. Should the first three = packets using the new key contain the EKT? Figure 6 (Handshake Message Flow) goes beyond the handshake messages. Section 5 says: An attacker could send packets containing a Full EKT Field, in an attempt to consume additional CPU resources of the receiving system by causing the receiving system will decrypt the EKT ciphertext and detect an authentication failure Since you recommend sending the EKT on more than one consecutive packet, = is there an easy way to avoid processing the same EKT on the subsequent = packets without doing all of the work? Section 5 says: The confidentiality, integrity, and authentication of the EKT cipher MUST be at least as strong as the SRTP cipher. Yes. But, there is more to say. If DTLS-SRTP is used, then there is = another ciphersuite that must be at least this strong as well. Section 6 asks: Do we need AES-192? No. Section 7 needs to cover two things: IANA registry for Message Type and = IANA registry EKT ciphers. Russ