Subject: [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

From: Spencer Dawkins <[email-masked]>
Date: Mon, 27 Oct 2014 13:48:43 -0500

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 <[email-masked]>
To: 	[email-masked]

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/

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Oct 2014 00:16:06 +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.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 17:37:49 -0700

> then we could. I'd ask Adam L. to write that though others

I think that my review strongly suggested removal of that text.  I
generally concur with agl on this point.  There are potentially even
cases where the intermediary won't see the initial round of the
handshake, so there is no chance of even seeing what *might* be
negotiated (not that you should be basing any decision on this marking
anyway).

Basically, this hook might be in the clear, or it might not.  Don't
expect to hang anything heavy on it.

---

From: Spencer Dawkins <[email-masked]>
Date: Tue, 28 Oct 2014 04:46:28 -0500

> expect to hang anything heavy on it.

So, you guys are the experts on this. Please feel free to clue me in.

What I was getting from Adam's Last Call comment was that this was a 
futures thing in the TLS working group, and that when the TLS working 
group delivers and what they deliver gets deployed, middleboxes won't be 
able to make policy decisions on based on ALPN labels because they'll be 
encrypted, so remove the text about making policy decisions based on 
ALPN labels because that will stop working.

What I was asking, was whether there was any reason to point out that 
until the TLS working group delivers, this is a possibility.

The current text included this possibility as a feature, and I 
understood Adam to be objecting to that characterization.

What I'm getting from this exchange is that it's not necessary to point 
out this possibility in the TRAM document as bug, either, because the 
bug applies to all ALPN labels, not just this one.

So, delete the existing text and don't add anything.

Am I tracking the conversation?

Thanks,

Spencer

---

From: Simon Perreault <[email-masked]>
Date: Tue, 28 Oct 2014 10:25:07 -0400

On Tue, Oct 28, 2014 at 5:46 AM, Spencer Dawkins <
[email-masked]> wrote:

> futures thing in the TLS working group, and that when the TLS working group
> delivers and what they deliver gets deployed, middleboxes won't be able to
> make policy decisions on based on ALPN labels because they'll be encrypted,
> so remove the text about making policy decisions based on ALPN labels
> because that will stop working.
>
> The current text included this possibility as a feature, and I understood
> Adam to be objecting to that characterization.
>
> out this possibility in the TRAM document as bug, either, because the bug
> applies to all ALPN labels, not just this one.
>

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?

Simon

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Oct 2014 17:25:40 -0700

On 28 October 2014 07:25, Simon Perreault <[email-masked]> wrote:
> 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.

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 29 Oct 2014 02:08:11 +0000

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

Cheers,

Gonzalo

> On Oct 28, 2014, at 8:25 PM, Martin Thomson <[email-masked]> wrote:
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Spencer Dawkins <[email-masked]>
Date: Wed, 29 Oct 2014 08:14:56 -0500

> 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 [email-masked]: 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

---

From: Simon Perreault <[email-masked]>
Date: Wed, 29 Oct 2014 09:56:29 -0400

On Tue, Oct 28, 2014 at 8:25 PM, Martin Thomson <[email-masked]>
wrote:

> are
> consulted.

Well, "concerned" is not the right term. I'm sure we're not breaking
anything and, further, we're very probably doing the right thing. I'm just
genuinely curious what immediate use cases there could be for this. The
ones I know are, shall we say, not politically correct: 1) middleboxes, and
2) "run everything on port 443".

> I'll confess, I always sort of assumed that you knew what

I'm guilty of this too. "Oh, right, ALPN for STUN/TURN, makes total sense."

Simon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 29 Oct 2014 14:59:34 +0000

Hi Spencer - 

I have sent the request for manual publication to [email-masked] as requested.

Thanks to all for your feedback.

Cheers,

Gonzalo

> On Oct 29, 2014, at 9:14 AM, Spencer Dawkins <[email-masked]> wrote:
> 
> 
> 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 [email-masked] cc: 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.
> 
>>> On 28 October 2014 07:25, Simon Perreault 
>>> <[email-masked]>
>>>  wrote:
>>>