Subject: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.txt

From: Alan Johnston <[email-masked]>
Date: Sat, 28 Jun 2014 12:04:49 -0500

All,

We have updated the STUN Origin draft.  The major changes relate to:

1. Adding sections on media keep-alive and SIP keep-alive usages
2. Adding a section on multiple origins
3. Adding a section on Implementation Status about the open source
implementations of the browser and STUN/TURN server that support the ORIGIN
attribute
4. Clarified integrity protection of the attribute in the Security
Considerations section.

These changes are based on all recent reviews and mailing list comments.

As always, comments are most welcome!

- Alan -

---------- Forwarded message ----------
From: <[email-masked]>
Date: Sat, Jun 28, 2014 at 11:50 AM
Subject: New Version Notification for draft-johnston-tram-stun-origin-03.txt
To: Kundan Singh <[email-masked]>, Alan Johnston <
[email-masked]>, John Yoakum <[email-masked]>, Justin Uberti <
[email-masked]>

A new version of I-D, draft-johnston-tram-stun-origin-03.txt
has been successfully submitted by Alan Johnston and posted to the
IETF repository.

Name:           draft-johnston-tram-stun-origin
Revision:       03
Title:          An Origin Attribute for the STUN Protocol
Document date:  2014-06-28
Group:          Individual Submission
Pages:          13
URL:
http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt
Status:
https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
Htmlized:
http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03
Diff:
http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03

Abstract:
   STUN, or Session Traversal Utilities for NAT, is a protocol used to
   assist other protocols traverse Network Address Translators or NATs.
   STUN, and STUN extensions such as TURN, or Traversal Using Relays
   around NAT, and ICE, Interactive Communications Establishment, have
   been around for many years but with WebRTC, Web Real-Time
   Communications, STUN and related extensions are about to see major
   deployments and implementation due to these protocols being
   implemented in browsers.  This specification defines an ORIGIN
   attribute for STUN that can be used in similar ways to the HTTP
   header field of the same name.  WebRTC browsers utilizing STUN and
   TURN would include this attribute which would provide servers with
   additional information about the STUN and TURN requests they receive.
   This specification defines the usage of the STUN ORIGIN attribute for
   web and SIP contexts.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jun 2014 10:16:59 -0700

Some nits on this sentence:

   For a web browser (HTTP User Agent), the contents of the ORIGIN
   attribute is the unicode-serialization of an origin defined in
   Section 6.1 of [RFC6454].

I think that using "for a web browser" here is redundant, since the
entire point of the document is that web browsers are the ones adding
this (other users are going to add whatever gets them what they want).

The second is that it's the UTF-8 encoding of the unicode-serialization.

And this sentence:

   [...]  It MUST contain a
   UTF-8 [RFC3629] encoded sequence of characters less than 268 bytes.
   The value of 268 is chosen to be larger than the maximum 253
   character domain name plus 8 characters for the URI scheme plus 5
   characters for the port number.

This arbitrary restriction doesn't seem like a great idea.  If the
coding efficiency of UTF-8 is strictly better than punycode, then it's
probably OK, but why be so strict?  Is there a strict need to limit
this to URIs with 5-character-or-less schemes?

On 28 June 2014 10:04, Alan Johnston <[email-masked]> wrote:
> To: Kundan Singh <[email-masked]>, Alan Johnston
> <[email-masked]>, John Yoakum <[email-masked]>, Justin Uberti
> <[email-masked]>
>
>
>
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 30 Jun 2014 18:13:48 +0000

Hi Alan,

My comments:

[1] Security Considerations:

Comment> You may want to add that If (D)TLS is used then STURN ORIGIN attribute cannot be modified by an intermediary.

[2] This information is often available in other messages sent by the browser, such as DNS or HTTP requests.

Comment>  Yes, but all these problems will most likely be addressed in future.  DNSOP WG is discussing various mechanisms for DNS privacy like DNS over (D)TLS and HTTP/2.0 mandates TLS.  New TLS extensions are discussed in TLS WG to encrypt TLS handshake for privacy reasons

[3] Section 2.4 ICE usage

Comment> You may also say that for consent checks (http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04), STUN ORIGIN attribute is not required.

[4] 2.4. ICE Usage

Comment> Any specific reason to say "NOT RECOMMENDED" ? why not say "MUST NOT use ORIGIN attribute" ?

[5] Senders MAY include multiple ORIGIN attributes in a request, and receivers MUST support parsing and receiving multiple ORIGIN attributes.

Comment> If path MTU is unknown then STUN messages over IPv4 would need to be less than 548 bytes (Section 7.1 of [RFC5389]). Sender must use this length restriction to limit the number of ORIGIN attributes in the STUN request.

[6]   STUN defines three authentication modes, depending on the STUN usage.

Comment> There are only two authentication modes !

[7] Suggest to split Introduction, have a separate section to discuss the problem.

[8] In addition to explicitly provisioning the realm value in the java script the other problem is exposing the user credentials to the JavaScript. http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-02 addresses this problem.

Thanks and Regards,

-Tiru

From: tram [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Saturday, June 28, 2014 10:35 PM
To: [email-masked]
Subject: [tram] Fwd: New Version Notification for draft-johnston-tram-stun-origin-03.txt

All,

1. Adding sections on media keep-alive and SIP keep-alive usages
2. Adding a section on multiple origins
3. Adding a section on Implementation Status about the open source implementations of the browser and STUN/TURN server that support the ORIGIN attribute
4. Clarified integrity protection of the attribute in the Security Considerations section.

- Alan -

---------- Forwarded message ----------
From: <[email-masked]<mailto:[email-masked]>>
Date: Sat, Jun 28, 2014 at 11:50 AM
Subject: New Version Notification for draft-johnston-tram-stun-origin-03.txt
To: Kundan Singh <[email-masked]<mailto:[email-masked]>>, Alan Johnston <[email-masked]<mailto:[email-masked]>>, John Yoakum <[email-masked]<mailto:[email-masked]>>, Justin Uberti <[email-masked]<mailto:[email-masked]>>

Name:           draft-johnston-tram-stun-origin
Revision:       03
Title:          An Origin Attribute for the STUN Protocol
Document date:  2014-06-28
Group:          Individual Submission
Pages:          13
URL:            http://www.ietf.org/internet-drafts/draft-johnston-tram-stun-origin-03.txt
Status:         https://datatracker.ietf.org/doc/draft-johnston-tram-stun-origin/
Htmlized:       http://tools.ietf.org/html/draft-johnston-tram-stun-origin-03
Diff:           http://www.ietf.org/rfcdiff?url2=draft-johnston-tram-stun-origin-03

Abstract:

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: Alan Johnston <[email-masked]>
Date: Mon, 30 Jun 2014 13:45:16 -0500

Martin,

Thanks for the feedback on the draft - see my replies below.

- Alan -

> The second is that it's the UTF-8 encoding of the unicode-serialization.
This paragraph, and the two following it define what this new attribute
carries. (The other two paragraphs begin "For a SIP User Agent..." and "For
a Jabber client...")  How about if I say instead:

"If inserted by a web browser, the ORIGIN attribute contains the UTF-8
encoding of the unicode-serialization of an origin defined in Section 6.1
of [RFC6454]."

> this to URIs with 5-character-or-less schemes?
I agree we don't want to limit it to 5-character-or-less URI schemes.  The
reason this text is there is because of concerns that this attribute will
make STUN messages too big. How much extra space should we allow.  Up to
280 octets?  Or should we just point out that origin strings from RFC6454
are likely to be around 253 octets long, and using strings that are
significantly longer is NOT RECOMMENDED.

---

From: Alan Johnston <[email-masked]>
Date: Mon, 30 Jun 2014 13:55:57 -0500

Hi Tiru,

Thanks for the close reading - see my comments below.

- Alan -

On Mon, Jun 30, 2014 at 1:13 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> Comment> You may want to add that If (D)TLS is used then STURN ORIGIN
> attribute cannot be modified by an intermediary.
>
>
Right.  I'll point this out.

> Comment>  Yes, but all these problems will most likely be addressed in
> future.  DNSOP WG is discussing various mechanisms for DNS privacy like DNS
> over (D)TLS and HTTP/2.0 mandates TLS.  New TLS extensions are discussed in
> TLS WG to encrypt TLS handshake for privacy reasons
>
>
>

Right.  I can soften this a bit to say "This information can be available
in other messages sent by the browser, such as DNS or HTTP request, unless
those protocols are using encryption."

> Comment> You may also say that for consent checks (
> http://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-04),
> STUN ORIGIN attribute is not required.
>
>
>
Agreed.  This is an extension to ICE, so I think it still counts as an ICE
usage, but I think it is worth saying explicitly.

> NOT use ORIGIN attribute" ?
I think NOT RECOMMENDED, effectively SHOULD NOT, is the right level here.
 There is no harm done (i.e. it doesn't cause any interop failures or
issues) if it is included, and we may come up with use cases in the future.
 I think ICE stacks should be prepared to receive an ORIGIN attribute, and
should just ignore it.

>
>
> [5] Senders MAY include multiple ORIGIN attributes in a request, and
> receivers MUST support parsing and receiving multiple ORIGIN attributes.
>
>
>
> Comment> If path MTU is unknown then STUN messages over IPv4 would need to
> be less than 548 bytes (Section 7.1 of [RFC5389]). Sender must use this
> length restriction to limit the number of ORIGIN attributes in the STUN
> request.
>
>
>

Good point.  I'll mention that including multiple Origin attributes
increases the size of STUN packets.

> Comment> There are only two authentication modes !
Well, there are three described in this paragraph: short term credential,
long term credential, and no credential (NULL).  I can make this clearer in
the text.

> [7] Suggest to split Introduction, have a separate section to discuss the
Yes, it is a bit large.  Some of this text, I think, can probably be
dropped, as it discusses alternative approaches which aren't described in
the document.  I can reorganize or condense.

>  [8] In addition to explicitly provisioning the realm value in the java
> script the other problem is exposing the user credentials to the
> JavaScript.
> http://tools.ietf.org/html/draft-reddy-tram-turn-third-party-authz-02
> addresses this problem.
>
>
>
Sure, this draft does nothing to solve that problem - it only addresses the
multi-realm issue.

>  Thanks and Regards,
>
> -Tiru
>
>
>
>
>
> *From:* tram [mailto:[email-masked]] *On Behalf Of *Alan Johnston
> *Sent:* Saturday, June 28, 2014 10:35 PM
> *To:* [email-masked]
> *Subject:* [tram] Fwd: New Version Notification for
> draft-johnston-tram-stun-origin-03.txt
>
>
>
> All,
>
>
>
> [email-masked]>, John Yoakum <[email-masked]>, Justin Uberti
> <[email-masked]>
>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 30 Jun 2014 13:23:25 -0700

On 30 June 2014 11:45, Alan Johnston <[email-masked]> wrote:
> make STUN messages too big. How much extra space should we allow.  Up to 280
> octets?  Or should we just point out that origin strings from RFC6454 are
> likely to be around 253 octets long, and using strings that are

That's probably best.  I don't think that people intentionally create
long names, but sometimes you have no choice.  IDN names do get pretty
large.