Re: [tram] 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

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Wed, 29 October 2014 13:15 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
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 D501E1A00B0 for <tram@ietfa.amsl.com>; Wed, 29 Oct 2014 06:15:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 NV_Q7dtm5yxq for <tram@ietfa.amsl.com>; Wed, 29 Oct 2014 06:15:12 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E3DF1A009E for <tram@ietf.org>; Wed, 29 Oct 2014 06:15:12 -0700 (PDT)
Received: by mail-ob0-f171.google.com with SMTP id wp18so2335627obc.30 for <tram@ietf.org>; Wed, 29 Oct 2014 06:15:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=rBALZuYqAyulbt2sM3Pl6FgrHcqnZgso8oyGjAKVZfA=; b=A0u+h/XdLS5Tedd++pme9/XvX1xRGSbWVhuxySyHiL7O4R+tAq3yBsjO0atjbxy4/h V4wkqSfB7BhBEB5FEV/tVhN4YyILYCpxeEXQcR1hkZjPgm9lJqigMk8Pl2583LN751v0 DzXlhaH6NIkU1B7C44NeVPfcLGyzWG6znLijvc3N1hDftGXv6DIUr1VhJIe1gi4VeGnj Swd62luiRIPbmTramilU29MNmKBcdHkwAD3nGN3HixPhA1WcqW6xOQpKdoiRLWYT6WWO z5va/7lfKSayhReDB++lyV8kptreU4ewO2QYuefT+T1V/NOM09dUXsc0mUXRwcJtGjfB yzmw==
X-Received: by 10.182.79.104 with SMTP id i8mr1768737obx.58.1414588511312; Wed, 29 Oct 2014 06:15:11 -0700 (PDT)
Received: from ?IPv6:2605:6000:9004:ce00:68e6:7992:7410:65f4? ([2605:6000:9004:ce00:68e6:7992:7410:65f4]) by mx.google.com with ESMTPSA id w82sm1805750oiw.27.2014.10.29.06.15.07 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 Oct 2014 06:15:09 -0700 (PDT)
Message-ID: <5450E850.9080609@gmail.com>
Date: Wed, 29 Oct 2014 08:14:56 -0500
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>, Martin Thomson <martin.thomson@gmail.com>
References: <CAMfhd9VXA2aqB7hF6TyP10dW0x1y5uM_UEgM7JuQB9yPW8B+Kg@mail.gmail.com> <544E938B.1030802@gmail.com> <544EE046.5080101@cs.tcd.ie> <CABkgnnUCoFTL5DC+Eq1oLkZU4ahkkc6Hw8nYUvayn-VFKbkHUQ@mail.gmail.com> <544F65F4.5080305@gmail.com> <CANO7kWDVHXKiqe6RT6uwpQJ4jGKVag8OS2B2nS55sNKLYU+meA@mail.gmail.com> <CABkgnnVyBi4SY6XUij6wovM302qWyLLtP47cfZqJudEAfL6cHA@mail.gmail.com> <F3146204-F404-4332-927B-F48A1E7C043C@cisco.com>
In-Reply-To: <F3146204-F404-4332-927B-F48A1E7C043C@cisco.com>
Content-Type: multipart/alternative; boundary="------------010800010909000803000808"
Archived-At: http://mailarchive.ietf.org/arch/msg/tram/WA09NImdy25r1i6y9eO3TFJ2gdU
Cc: "tram@ietf.org" <tram@ietf.org>, tls chair <tls-chairs@tools.ietf.org>, Martin Stiemerling <mls.ietf@gmail.com>, Simon Perreault <sperreault@jive.com>, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>, Adam Langley <agl@imperialviolet.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [tram] 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: Wed, 29 Oct 2014 13:15:18 -0000

On 10/28/2014 09:08 PM, Gonzalo Salgueiro (gsalguei) wrote:
>  From the authors' perspective I think we have what we need to produce the next version of the document that satisfies the recently raised concerns regarding the sample use cases.  We will trim this purely informational text as it is not in line with forward-looking end-to-end security best practices as we have no desire to propagate misconceptions or unsound approaches, no matter if it is non-normative text or not. I think we also all agree that this document is nothing more than the registration of a new label and not the place to expound on those more generally applicable best practices for ALPN. We're confident that the text removal will result in no loss of information with respect to what we are standardizing in this draft.
>
> Does this sound like a reasonable way forward?

I'm still listening, if other people have input, but that's where I 
think we are now.

And I agree that a TRAM document is not the right place to talk about 
ALPN labels in a general way - that was why I asked for guidance from 
the TLS folks.

If you know what the draft should say (and not say), please feel free to 
send the revision to be posted to ietf-action@ietf.orgcc: me, requesting 
manual posting, and I'll approve it and leave it on the next telechat 
agenda (where it is currently).

Otherwise, the automated submission tool will start working again on 
2014-11-10.

And thank you all for your help with this.

Spencer

> Cheers,
>
> Gonzalo
>
>
>
>> On Oct 28, 2014, at 8:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> On 28 October 2014 07:25, Simon Perreault <sperreault@jive.com> wrote:
>>> Re-reading the draft again, if we delete those use cases, we are left
>>> with... nothing. I don't see any use case for ALPN in STUN/TURN that does
>>> not involve middleboxes. I don't see the point of STUN usage negotiation
>>> since all usages speak the same protocol (STUN) and will be "negotiated"
>>> implicitly later on, when a usage-specific message is emitted. So... why are
>>> we doing this again?
>> What ALPN does is provide an unambiguous identification of the
>> intended protocol.  That allows for use of multiple protocols (TURN v2
>> perhaps!) on the same port.  The uses for HTTP and WebRTC do this
>> already.  Maybe it's not important for TURN.
>>
>> If you are concerned about this, perhaps the working group might be
>> consulted.  I'll confess, I always sort of assumed that you knew what
>> you were doing here, so I didn't think much on the issue.
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram