Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Marc Petit-Huguenin <petithug@acm.org> Thu, 03 May 2018 23:34 UTC

Return-Path: <petithug@acm.org>
X-Original-To: tram@ietfa.amsl.com
Delivered-To: tram@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA74612DA43; Thu, 3 May 2018 16:34:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.441
X-Spam-Level:
X-Spam-Status: No, score=-0.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 rpPRZKHRICqy; Thu, 3 May 2018 16:34:53 -0700 (PDT)
Received: from implementers.org (unknown [IPv6:2001:4b98:dc0:45:216:3eff:fe7f:7abd]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B06AD12DA05; Thu, 3 May 2018 16:34:53 -0700 (PDT)
Received: from [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd] (unknown [IPv6:2001:0:53aa:64c:18b5:3a25:f31a:9fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 75022AE844; Fri, 4 May 2018 01:34:49 +0200 (CEST)
From: Marc Petit-Huguenin <petithug@acm.org>
To: Eric Rescorla <ekr@rtfm.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-stunbis@ietf.org, tram-chairs@ietf.org, Gonzalo.Camarillo@ericsson.com, tasveren@rbbn.com, tram@ietf.org
References: <152390863222.19652.10310304989315386136.idtracker@ietfa.amsl.com> <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org>
Message-ID: <31a441d2-8843-c8ee-f5ef-5496e5b4b364@acm.org>
Date: Thu, 3 May 2018 16:34:47 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <c0a06754-6f8c-97dc-7f7e-26a7df43e842@acm.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/s5UD7ZNk2i9Jvid3CKBEQgAayc8>
Subject: Re: [tram] Eric Rescorla's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 03 May 2018 23:34:56 -0000

On 04/22/2018 02:02 PM, Marc Petit-Huguenin wrote:
> Hi Eric,
> 
> Thanks for the review, please see my responses inline.
> 
> On 04/16/2018 12:57 PM, Eric Rescorla wrote:
>> Eric Rescorla has entered the following ballot position for
>> draft-ietf-tram-stunbis-16: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-tram-stunbis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> Rich version of this review at:
>> https://mozphab-ietf.devsvcdev.mozaws.net/D5132
>>
>>
>> Can you please indicate how you addressed the points Matt Miller
>> raised in his secdir review about the use of MD5.
> 
> From my response on 2018-03-11:
> 
>> * The description for 17.5.1. "MD5" list the key size as 20 bytes, but the
>> hash length of MD5 is 16 bytes (128 bits).  I think this is merely a typo,
>> since the purpose appears to be for backwards compatibility with existing
>> systems.
> 
> Fixed.
> 
>>
>> * Both 17.5.1.1. "MD5" Section 9.2.2. "HMAC Key" (long-term credential)
>> and Section appear to define the same functional algorithm, but with subtle
>> syntax differences.  As far as I can tell, they are actually the same
>> algorithm; would it not be acceptable to have Section 9.2.2 point to
>> Section 17.5.1.1 for the algorithm description?
>>
>>
> 
> This is going into the IANA registry so I left things there.  I fixed the discrepancy with section 9.2.2.
> 
> I also fixed the definition of the key for SHA-256, which must use OpaqueString for the realm.
> 
>>
>>
>>
>> DETAIL
>>>      by the agent sending the indication.  It primarily serves to
>>>      correlate requests with responses, though it also plays a small role
>>>      in helping to prevent certain types of attacks.  The server also uses
>>>      the transaction ID as a key to identify each transaction uniquely
>>>      across all clients.  As such, the transaction ID MUST be uniformly
>>>      and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
>>
>> I didn't realize this was a SHOULD. ICE depends on it as a security
>> condition, so it probably needs to be a MUST.
> 
> Done.
> 
>>
>>
>>>      For a request or indication message, the agent MUST include the
>>>      USERNAME, MESSAGE-INTEGRITY-SHA256, and MESSAGE-INTEGRITY attributes
>>>      in the message unless the agent knows from an external indication
>>>      which message integrity algorithm is supported by both agents.  In
>>>      this case either MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 MUST
>>>      be included in addition to USERNAME.  The HMAC for the MESSAGE-
>>
>> This text appears to conflict with S 7.3 of 5245-bis, which says:
> 
> [text missing]
> 
> Hmm, no, RFC245bis is still referencing RFC5389, so the procedure for stunbis does not apply.
> 
>>
>>
>>>      STUN Security Feature it is understood that the corresponding STUN
>>>      Security Feature bit in the "nonce cookie" is set to 1.
>>>
>>>      For example, in Section 9.2.4 discussing the PASSWORD-ALGORITHMS
>>>      security feature, it is implied that the "Password algorithms" bit,
>>>      as defined in Section 17.1, is set to 1 in the "nonce cookie".
>>
>> I'm not sure I understand the bid down attack here or the proposed
>> defense.  Can you please walk through what the assumed attacker
>> capabilities are, what the client and server capabilities are, how the
>> bid down attack works, and how this protects against it?
> 
> The plan is to add an annex to the document explaining that.  I'll finish to process the other reviews from the IESG and then come back to that.
> 

Instead of an annex, we added a new section in the Security Considerations.  Please have a look at -17 and let us know if that explanation is good enough.

Thanks.