Subject: [tram] STUN-bis adoption call

From: Simon Perreault <[email-masked]>
Date: Fri, 24 Oct 2014 06:50:58 -0600

TRAMsters,

This email starts a two-week adoption call for
draft-salgueiro-tram-stunbis-02
<http://datatracker.ietf.org/doc/draft-salgueiro-tram-stunbis/> to fulfill
the STUN-bis milestone that we have.

Let's focus the discussion on the high-level direction this draft is going.
If you agree or disagree with it, please explain why. The authors have
provided a list of the top issues to help focus this discussion. Please
also see Appendix B in the draft.

   1.   STUN hash algorithm agility (currently only SHA-1 is allowed) with
a new message-integrity attribute (following 16.3).

   2.   Integrate RFC 5769 (stun vectors) as examples

   3.   Integrate RFC 7350 (dtls) and RFC 7064 (URI)

   4.   Clarify text on RTP caching in section 7.2.1..

   5.   Clarify terminology, text and guidance for STUN fragmentation.

   6.   Fix bug on retransmission RTO in section 7.2.

   7.   Address existing errata (2010, 2972, 3737).

   8.   Fix bug on retransmission RTO in section 7.2.

   9.  Clarify whether it's valid to share nonces across TURN
        allocations.  Clarify nonce behavior for both invalid and
        expired nonces.  Right now only expired nonces are described.
        Define a new "invalid nonce" error code (presumably 438)

Please send your comments before November 7, 2014.

Thanks,
Simon & Gonzalo

---

From: Brandon Williams <[email-masked]>
Date: Fri, 24 Oct 2014 10:21:57 -0400

I'm not completely certain what you mean by "high-level direction". You 
could be referring to the general degree of coverage, or you could mean 
the general approach taken for each item. I'll respond to both.

In terms of the degree of coverage, I think this is a good list, though 
I could easily be missing something because there are really only two 
items that I've been particularly concerned about and they are both 
covered (hash agility and framentation). If you would like the adoption 
call to focus on coverage with an assumption that we'll fix content 
later, then I support adoption.

In terms of the approach taken for the two items I'm most focused on, 
I've got concerns (see below). If you would like the adoption call to 
focus on high-level agreement with the proposed approach, then I think 
the document needs some more work before I would support adoption.

Regarding fragmentation (item 5) ... I don't see any substantive 
changes. I don't see anything about this in appendix B.2, so I don't 
think I'm missing anything.

Regarding hash agility (item 1) ... I've got a few concerns about the 
currently proposed approach.

First, There was a discussion about hash agility on the list with 
reference to third party auth, and the currently proposed approach 
doesn't reflect the content of that discussion. In particular, I would 
not describe this proposal as "agile". It has the same shortcomings as 
the 5389 approach in that regard, locking us into a specific alternate 
algorithm rather than defining the mechanisms necessary for moving to 
new agorithms in the future.

Next, it describes using an HMAC-SHA256 key size for long term 
credentials that falls outside of the recommendation from the relevant 
HMAC spec, which strongly discourages key lengths shorter than the 
algorithm's output length. This problem already exists in rfc5389 for 
SHA1, but I hope we can either come up with a way to correct it or 
provide an explanation of why STUN does not follow the guidance.

Finally, there has been some discussion on the list about concerns 
regarding the use of MD5 for generation and storage of keys and a hope 
that we could move away from that mechanism. I'm not particularly 
concerns about that myself, since we would be using the third party auth 
mechanism. That said, I was expecting to see some reference to these 
concerns in the context of hash agility. Perhaps that item just hasn't 
been addressed yet and will be in a future revision.

--Brandon

On 10/24/2014 08:50 AM, Simon Perreault wrote:
> <http://datatracker.ietf.org/doc/draft-salgueiro-tram-stunbis/> to
> fulfill the STUN-bis milestone that we have.
>
> Let's focus the discussion on the high-level direction this draft is
> going. If you agree or disagree with it, please explain why. The authors
> have provided a list of the top issues to help focus this discussion.
> Please also see Appendix B in the draft.
>
>     1.   STUN hash algorithm agility (currently only SHA-1 is allowed)
> with a new message-integrity attribute (following 16.3).
>

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 25 Oct 2014 03:10:14 +0000

> -----Original Message-----
> From: tram [mailto:[email-masked]] On Behalf Of Brandon Williams
> Sent: Friday, October 24, 2014 7:52 PM
> To: [email-masked]
> Subject: Re: [tram] STUN-bis adoption call
> 
> could be referring to the general degree of coverage, or you could mean the
> general approach taken for each item. I'll respond to both.
> 
> In terms of the degree of coverage, I think this is a good list, though I could
> easily be missing something because there are really only two items that I've
> been particularly concerned about and they are both covered (hash agility
> and framentation). If you would like the adoption call to focus on coverage
> with an assumption that we'll fix content later, then I support adoption.
> 
> In terms of the approach taken for the two items I'm most focused on, I've
> got concerns (see below). If you would like the adoption call to focus on high-
> level agreement with the proposed approach, then I think the document
> needs some more work before I would support adoption.
> 
> Regarding fragmentation (item 5) ... I don't see any substantive changes. I
> don't see anything about this in appendix B.2, so I don't think I'm missing
> anything.

There were discussions about fragmentation support in the list sometime back but without any conclusions. 
Please provide more details.

> 
> Regarding hash agility (item 1) ... I've got a few concerns about the currently
> proposed approach.
> 
> First, There was a discussion about hash agility on the list with reference to
> third party auth, and the currently proposed approach doesn't reflect the
> content of that discussion. In particular, I would not describe this proposal as
> "agile". It has the same shortcomings as the 5389 approach in that regard,
> locking us into a specific alternate algorithm rather than defining the
> mechanisms necessary for moving to new agorithms in the future.

+1

> 
> Next, it describes using an HMAC-SHA256 key size for long term credentials
> that falls outside of the recommendation from the relevant HMAC spec,
> which strongly discourages key lengths shorter than the algorithm's output
> length. This problem already exists in rfc5389 for SHA1, but I hope we can
> either come up with a way to correct it or provide an explanation of why
> STUN does not follow the guidance.

Yup, http://tools.ietf.org/html/rfc4868#section-2.1.1 discusses the above point and section 14.5 needs to be fixed

<snip>
   HMAC-SHA-256+ are secret key algorithms.  While no fixed key length
   is specified in [HMAC], this specification requires that when used as
   an integrity/authentication algorithm, a fixed key length equal to
   the output length of the hash functions MUST be supported, and key
   lengths other than the output length of the associated hash function
   MUST NOT be supported.
</snip>

> 
> Finally, there has been some discussion on the list about concerns regarding
> the use of MD5 for generation and storage of keys and a hope that we could
> move away from that mechanism. I'm not particularly concerns about that
> myself, since we would be using the third party auth mechanism. 

But when TURN server is deployed in Enterprise network then it may have to support both first and third party mechanisms. 
The problem with MD5 is documented in https://tools.ietf.org/html/rfc7376#section-4.

Cheers,
-Tiru

> That said, I
> was expecting to see some reference to these concerns in the context of hash
> agility. Perhaps that item just hasn't been addressed yet and will be in a
> future revision.
> 
> --Brandon
> 
> > going. If you agree or disagree with it, please explain why. The
> > authors have provided a list of the top issues to help focus this discussion.
> Brandon Williams; Senior Principal Software Engineer Emerging Products
> Engineering; Akamai Technologies Inc.
> 
> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram

---

From: Brandon Williams <[email-masked]>
Date: Mon, 27 Oct 2014 10:19:40 -0400

> Please provide more details.

My primary point is that improved guidance on fragmentation and message 
sizes is one of the things on the list of open items and it doesn't 
appear that any changes have been made yet. I mostly wanted to confirm 
that there isn't something about this already in the document that I'm 
not seeing.

--Brandon

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Wed, 29 Oct 2014 06:21:39 +0000

Brandon - 

You raise a valid point that bears some clarification.  For the purposes of WG adoption, let's focus on agreeing to the list of items we want to tackle.  Once we have a WG draft, we can iterate on the actual text to ensure we have text that is representative of WG consensus.

Cheers,

Gonzalo

> On Oct 27, 2014, at 10:19 AM, Brandon Williams <[email-masked]> wrote:
> 
> My primary point is that improved guidance on fragmentation and message sizes is one of the things on the list of open items and it doesn't appear that any changes have been made yet. I mostly wanted to confirm that there isn't something about this already in the document that I'm not seeing.
> 
> --Brandon
> 
> --

---

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

On Wed, Oct 29, 2014 at 2:21 AM, Gonzalo Salgueiro (gsalguei) <
[email-masked]> wrote:

> You raise a valid point that bears some clarification.  For the purposes
> of WG adoption, let's focus on agreeing to the list of items we want to
> tackle.  Once we have a WG draft, we can iterate on the actual text to
> ensure we have text that is representative of WG consensus.

Correct. A working group may decide to adopt a draft with conditions, e.g.,
"adopt on condition that such and such issue be resolved in such and such
manner in the next revision".

Simon

---

From: Brandon Williams <[email-masked]>
Date: Thu, 30 Oct 2014 17:54:51 -0400

Thanks for that clarification on intent.

It allows me to give an unambiguous

+1 on adoption

--Brandon

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 31 Oct 2014 16:02:39 +0000

+1 to adoption.

.-.
Pål-Erik

On 30 Oct 2014, at 22:54, Brandon Williams <[email-masked]<mailto:[email-masked]>> wrote:

+1 on adoption

--Brandon

Cheers,

Gonzalo

On Oct 27, 2014, at 10:19 AM, Brandon Williams <[email-masked]<mailto:[email-masked]>> wrote:

--Brandon

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tram

---

From: Oleg Moskalenko <[email-masked]>
Date: Fri, 31 Oct 2014 09:37:37 -0700

+1

On Fri, Oct 31, 2014 at 9:02 AM, Pal Martinsen (palmarti) <
[email-masked]> wrote:

>  +1 to adoption.
>
>  .-.
> Pål-Erik
>
>  On 30 Oct 2014, at 22:54, Brandon Williams <[email-masked]>
> wrote:
>
> sizes is one of the things on the list of open items and it doesn't appear
> that any changes have been made yet. I mostly wanted to confirm that there
> isn't something about this already in the document that I'm not seeing.
>
> --Brandon
>
> --