Subject: [TLS] Fwd: New Version Notification for draft-thomson-tls-acp-00.txt

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Mar 2014 09:38:46 +0000

Just so that folks don't wonder about what this is about, there's a
thread in rtcweb@ that I've started on the topic.  This extension
might be required to support some security features in WebRTC.

For those interested, there is some more context in this thread:
http://www.ietf.org/mail-archive/web/rtcweb/current/msg11755.html

---------- Forwarded message ----------

Name:           draft-thomson-tls-acp
Revision:       00
Title:          Authenticated Content Promise Extension for (D)TLS
Document date:  2014-03-06
Group:          Individual Submission
Pages:          5
URL:            http://www.ietf.org/internet-drafts/draft-thomson-tls-acp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-thomson-tls-acp/
Htmlized:       http://tools.ietf.org/html/draft-thomson-tls-acp-00

Abstract:
   This document describes an extension to Transport Layer Security
   (TLS) and Datagram TLS (DTLS) that enables the negotiation of a
   promise to protect session content from modification and
   eavesdropping by third parties.

---

From: Adam Langley <[email-masked]>
Date: Sat, 8 Mar 2014 15:30:37 -0500

> might be required to support some security features in WebRTC.

Seems like this could be easily supported with ALPN, no?

Cheers

AGL

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Mar 2014 07:00:15 +0000

> Seems like this could be easily supported with ALPN, no?

Yes.  I thought of that.  You could use ALPN to signal all sorts of
things.  I'd prefer to avoid overloading ALPN in that way.

In this case, it might be OK, but combining generic semantics into
ALPN generates exponentially more tokens.  Maybe it's just a reaction
to suggestions of a need for structured ALPN tokens, which is a
recurring theme in HTTP/2 discussions.  I want to avoid getting into
that situation, which means that I favour extension over an increasing
reliance on ALPN.

---

From: Watson Ladd <[email-masked]>
Date: Sun, 9 Mar 2014 00:33:02 -0800

> that situation, which means that I favour extension over an increasing

Why does this need an extension? It seems you can send it over the
channel inside TLS with no trouble.

Sincerely,
Watson Ladd
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Sun, 9 Mar 2014 09:41:01 +0000

> channel inside TLS with no trouble.

The specific use case that caused me to write this draft doesn't work
that way.  DTLS-SRTP (RFC5764) doesn't use application data; it's just
a handshake followed by extractors (RFC 5705).

It is possible to use RTP header extensions to carry an indication and
rely on RTCP feedback to obtain acknowledgement, but that is
significantly more complex, it has new failure modes (RTP header
extensions have to be negotiated and are by definition ignorable) and
results in interoperability issues (RTP header extensions have been
known to cause issues).