Subject: [Perc] KMF/MDD interface: thoughts on a new approach

From: Adam Roach <[email-masked]>
Date: Sat, 16 Jul 2016 10:39:44 +0200

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

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 18 Jul 2016 08:02:06 -0400

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 <[email-masked]> 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.
> 
> 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:
> 
> 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.
> 
> 
> |           SCTP            |  <- Provides control channel reliability, channel IDs
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perc

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Jul 2016 09:06:20 +0200

Rather than inventing something new, I'd like to suggest that we just
define a web services interface from the KMF to the MDD. As soon as you're
not on the same path as the DTLS messages, then you lose the benefits of
the implicit binding between the DTLS messages and the control messages,
and then this just becomes a straight-up question of what's the easiest way
to build a control channel between machine A and  machine B. And I think at
this point we have a fair amount of experience that the natural thing to do
here is HTTPS (cf. ACME)

-Ekr

On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <[email-masked]> wrote:

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

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 22 Jul 2016 09:19:12 +0200

how would you imaging the message that are initiated from Media Distributor to the Key Distributor gong ? Websockets ?

> On Jul 22, 2016, at 9:06 AM, Eric Rescorla <[email-masked]> wrote:
> 
> Rather than inventing something new, I'd like to suggest that we just define a web services interface from the KMF to the MDD. As soon as you're not on the same path as the DTLS messages, then you lose the benefits of the implicit binding between the DTLS messages and the control messages, and then this just becomes a straight-up question of what's the easiest way to build a control channel between machine A and  machine B. And I think at this point we have a fair amount of experience that the natural thing to do here is HTTPS (cf. ACME)
> 
> -Ekr
> 
> 
> On Mon, Jul 18, 2016 at 2:02 PM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> > On Jul 16, 2016, at 4:39 AM, Adam Roach <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/perc <https://www.ietf.org/mailman/listinfo/perc>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Jul 2016 10:08:25 +0200

On Fri, Jul 22, 2016 at 9:19 AM, Cullen Jennings <[email-masked]> wrote:

>
> how would you imaging the message that are initiated from Media
> Distributor to the Key Distributor gong ? Websockets ?
>

I think there are two choices:

1. Have two channels, one of which is (D)TLS and one of which is HTTPS.
Note that if it's DTLS you need some sort of ICE-type story on the DTLS
channel.
2. Have everything over HTTPS, in which case it's WebSockets.

-Ekr

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

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Jul 2016 10:10:37 +0200

I think all proposals keep the MDD in the path.

pj

-------- Original Message --------
From: Eric Rescorla <[email-masked]>
Sent: July 22, 2016 9:06:20 AM GMT+02:00
To: Cullen Jennings <[email-masked]>
Cc: Adam Roach <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

-Ekr

> this will be easier to specify and easier to implement.

------------------------------------------------------------------------

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Jul 2016 10:27:20 +0200

Well, at least one design is to have two parallel connections, one DTLS and
one HTTPS

-Ekr

On Fri, Jul 22, 2016 at 10:10 AM, Paul E. Jones <[email-masked]>
wrote:

> ------------------------------
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* July 22, 2016 9:06:20 AM GMT+02:00
> *To:* Cullen Jennings <[email-masked]>
> *Cc:* Adam Roach <[email-masked]>, "[email-masked]" <[email-masked]>
> *Subject:* Re: [Perc] KMF/MDD interface: thoughts on a new approach
>
> ------------------------------
>
> Perc mailing list
> [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 22 Jul 2016 10:32:07 +0200

We've not had that proposal until today. We did discuss having a HTTPS connection long ago, but people preferred DTLS-SRTP and bundling MDD interface with that.

Paul

-------- Original Message --------
From: Eric Rescorla <[email-masked]>
Sent: July 22, 2016 10:27:20 AM GMT+02:00
To: "Paul E. Jones" <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, Adam Roach <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Perc] KMF/MDD interface: thoughts on a new approach

-Ekr