Re: [tram] Fwd: Last Call: <draft-ietf-tram-alpn-06.txt> (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard

Stephen Farrell <stephen.farrell@cs.tcd.ie> Tue, 28 October 2014 00:16 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A89B1A8791 for <tram@ietfa.amsl.com>; Mon, 27 Oct 2014 17:16:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 a9f9IxtTOgdW for <tram@ietfa.amsl.com>; Mon, 27 Oct 2014 17:16:09 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2699E1A879A for <tram@ietf.org>; Mon, 27 Oct 2014 17:16:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7DF9EBDD0; Tue, 28 Oct 2014 00:16:08 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ5MW1mGYNR2; Tue, 28 Oct 2014 00:16:06 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.46.26.9]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A330CBE1D; Tue, 28 Oct 2014 00:16:06 +0000 (GMT)
Message-ID: <544EE046.5080101@cs.tcd.ie>
Date: Tue, 28 Oct 2014 00:16:06 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
References: <CAMfhd9VXA2aqB7hF6TyP10dW0x1y5uM_UEgM7JuQB9yPW8B+Kg@mail.gmail.com> <544E938B.1030802@gmail.com>
In-Reply-To: <544E938B.1030802@gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/3CShOAqGqg9Vnin3OEQ5hHIoras
Cc: Adam Langley <agl@imperialviolet.org>, Martin Stiemerling <mls.ietf@gmail.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, "tram@ietf.org" <tram@ietf.org>, tls-chairs@tools.ietf.org
Subject: Re: [tram] Fwd: Last Call: <draft-ietf-tram-alpn-06.txt> (Application Layer Protocol Negotiation (ALPN) labels for Session Traversal Utilities for NAT (STUN) Usages) to Proposed Standard
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Oct 2014 00:16:12 -0000

Hiya,

Brief response sorry. Yes, TLS1.3 aims to encrypt ALPN labels
as a deliberate specific goal. NPN (the pre-standards ALPN)
which is in use and is functionally the same, already does
this for TLS1.2, so even current deployments cannot assume
that such labels are clear as some may prefer to deploy with
NPN until TLS1.3.

Not sure we're in a position to write ALPN guidance as you'd
like right now, but were it just a paragraph like the above,
then we could. I'd ask Adam L. to write that though others
could be as good.

S.

On 27/10/14 18:48, Spencer Dawkins wrote:
> Hi, Stephen, the responsible AD for TLS WG,
> 
> I could be all wrong about this, but what I think is going on is ...
> 
> As part of IETF Last Call for draft-ietf-tram-alpn-06.txt, we got a
> thought-provoking comment from Adam Langley, objecting to an observation
> in the draft that STUN ALPN labels could be used by middleboxes to
> enforce policy, because doing so runs head on into chartered work in TLS
> to encrypt as much of the TLS handshake as possible.
> 
> In subsequent exchanges, Adam and the TRAM folk agreed that this is true
> for any ALPN label, not just for STUN ALPN labels.
> 
> The TRAM folk aren't comfortable adding discussions about this broader
> issue in a TRAM document. The most recent proposal was to remove the
> text that points out this possibility.
> 
> I'm thinking that removing the text that says it's possible to use STUN
> ALPN labels may not be the best response to Adam's comment (even in "The
> Wizard of Oz", the man behind the curtain saying, "pay no attention to
> the man behind the curtain" didn't change the fact that there's still a
> man behind the curtain).
> 
> Would a document about ALPN label abuse, regardless of the specific
> label, be appropriate for the TLS working group, if the TLS working
> group thought this question mattered enough to work on it?
> 
> I've slipped draft-ietf-tram-alpn from this week's telechat to 11/25, so
> we have time to talk about this question without bouncing a Discuss
> around, and people can talk at IETF 91 if that's helpful.
> 
> Thanks for any guidance you can provide.
> 
> Spencer, as shepherding AD for draft-ietf-tram-alpn
> 
> -------- Forwarded Message --------
> Subject:     Last Call: <draft-ietf-tram-alpn-06.txt> (Application Layer
> Protocol Negotiation (ALPN) labels for Session Traversal Utilities for
> NAT (STUN) Usages) to Proposed Standard
> Date:     Wed, 8 Oct 2014 10:24:08 -0700
> From:     Adam Langley <agl@imperialviolet.org>
> To:     ietf@ietf.org
> 
> 
> 
> In the introduction of this document[1], the first example appears to
> endorse the idea that a firewall would inspect a TLS handshake and
> quash the communication if it saw an ALPN identifier that it didn't
> like.
> 
> If I'm not misunderstanding this example, then it's contradictory to
> the work that the TLS WG is chartered to do[2]:
> 
> "Develop a mode that encrypts as much of the handshake as is possible
> to reduce the amount of observable data to both passive and active
> attackers."
> 
> It would be disappointing if an RFC explicitly endorsed middleware
> that tries to parse high-level protocols and interferes with the
> network based on the result. There might not be much that we can do
> about it, but we don't have to condone it.
> 
> 
> Cheers
> 
> AGL
> 
> 
> [1] https://tools.ietf.org/html/draft-ietf-tram-alpn-06#section-1
> [2] https://datatracker.ietf.org/doc/charter-ietf-tls/
>