Re: [tram] Contradictions in RFC8489

Dan Wing <danwing@gmail.com> Fri, 26 February 2021 19:36 UTC

Return-Path: <danwing@gmail.com>
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 D20F73A15C3 for <tram@ietfa.amsl.com>; Fri, 26 Feb 2021 11:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 N4k4LWR59FwA for <tram@ietfa.amsl.com>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A4F3A15C1 for <tram@ietf.org>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
Received: by mail-pf1-x434.google.com with SMTP id d12so4389022pfo.7 for <tram@ietf.org>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=v4jxQK4P8ZM3NXbb3OVDasF8GjarFgLorUjvVfMz39M=; b=iG/+FSHkPtbtpIY9VMAuIw7sKeq64MxVZB7Dry2/zk2V6ROGE5OH8VunXeAKmPDEhx 96+qDVR1IjjxGIL148OfqRLdU9+r+ViMIFkEKK197i+97gjJiu3YyICcr0FeG2D7NsKd w/WI33OYSqBK8VHRkVcSKJhuKtBr97iSW0KSttE3proIGApxd6+hkbeBY2MPjPOd8i8C gUaJN9hGLgaqLy8LdqPcqt4UBgIWLFq15SkxXx/BcNC59HrJ2WvUVqNM+gYrTPl49CtM XMtNYrI6921huS0d6ej+GAmxgDSjZFv8K9cN9IrJ4uPh0cOekjmdtpEx0HVe5AGsmk/m 0XbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=v4jxQK4P8ZM3NXbb3OVDasF8GjarFgLorUjvVfMz39M=; b=Z8ginz2ip8WwHc6Kgd68X+UWVrZ8wwa/S3ktUcAHm679qOvaV199PecguxErOdvQk8 Bnyq8tXET8lVrRQDCTCTD/i66JzPmaliljgJlK5K+XwAaDcV2rAmEMUf/UsHydPsS/12 BaB0MNEzUqflGXAeE8P3ZW3SRluSmY4txDVrb0C+57a4LujuuRbeVIweE25kQpohM8lc Q/vcM4IGLZVZfqv5MMfFbiRz/03l4chOvqMa44/Oj/o/flPjreBjqEh/v7tbh9SyZ8Re 3uFc9UYGly6JCT3guEsyx2ccOpS1PDq/OQUasLfWVlOcaJ0UqxK8uEYGNBuk8MVIo9o0 ZFkQ==
X-Gm-Message-State: AOAM5312t9eKi32FUR58vVQyl4AR1ToZVckGxAP33/gEdVIRERYrqhXR K6MwvYxOm6K5nEAZWduWwT8=
X-Google-Smtp-Source: ABdhPJwduChFhuGeTTPKHD0GUM7R3oF3QPM+kUr75lXNNP4MgzgYve2Gq6MAs5z5kVsEGnerv2WfSQ==
X-Received: by 2002:aa7:9d9b:0:b029:1ed:6c08:b93c with SMTP id f27-20020aa79d9b0000b02901ed6c08b93cmr4654400pfq.37.1614368197384; Fri, 26 Feb 2021 11:36:37 -0800 (PST)
Received: from [192.168.1.60] (47-208-190-34.trckcmtc01.res.dyn.suddenlink.net. [47.208.190.34]) by smtp.gmail.com with ESMTPSA id 2sm10041783pfi.116.2021.02.26.11.36.36 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 11:36:36 -0800 (PST)
From: Dan Wing <danwing@gmail.com>
Message-Id: <924F7C3A-B9A5-4648-ADC2-704EF78B8698@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BFCA44BA-A862-46BE-AC2C-C6732C411CB8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
Date: Fri, 26 Feb 2021 11:36:35 -0800
In-Reply-To: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com>
Cc: "tram@ietf.org" <tram@ietf.org>
To: Nils Ohlmeier <nohlmeier@mozilla.com>
References: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/BP9GwSntE0dD_cYGEAZ7dvZVjQI>
Subject: Re: [tram] Contradictions in RFC8489
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 26 Feb 2021 19:36:40 -0000


> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <nohlmeier@mozilla.com> wrote:
> 
> Hello,
> 
> I recently learned about an interesting contradiction in RFC 8489.
> 
> When it comes to using the 300 responses with Alternate-Server attributes section 10 https://tools.ietf.org/html/rfc8489#section-10 says:
> 
> The error response message MAY be
>    authenticated; however, there are use cases for ALTERNATE-SERVER
>    where authentication of the response is not possible or practical.
> 
> But then section 14.8 https://tools.ietf.org/html/rfc8489#section-14.8 in regards to 300 responses says:
> 
> This error response MUST be protected with the
>         MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
>         receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
>         INTEGRITY-SHA256 of this response before redirecting themselves
>         to an alternate server.

There is some surrounding text of 14.8 which seems relevant, which I have bolded and marked with **,

   300  Try Alternate: The client should contact an alternate server for
        this request.  **This error response MUST only be sent if the
        request included either a USERNAME or USERHASH attribute and a
        valid MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute;
        otherwise, it MUST NOT be sent and error code 400 (Bad Request)
        is suggested**.  This error response MUST be protected with the
        MESSAGE-INTEGRITY or MESSAGE-INTEGRITY-SHA256 attribute, and
        receivers MUST validate the MESSAGE-INTEGRITY or MESSAGE-
        INTEGRITY-SHA256 of this response before redirecting themselves
        to an alternate server.

        Note: Failure to generate and validate message integrity for a
        300 response allows an on-path attacker to falsify a 300
        response thus causing subsequent STUN messages to be sent to a
        victim.

I interpret the bolded sentence and the next sentence (starting with "This error ...") to mean: if the request arrived with USERNAME/USERHASH and valid MESSAGE-INTEGRITY(-256), then the response has to also contain MESSAGE-INTEGRITY(-256), else the response cannot be 300 Try Alternative (and recommends using response 400).

-d



> Looking at the previous RFC’s it looks like this contradiction has been in the STUN/TURN RFCs for a long time already.
> 
> I became aware of this problem, because it is causing interop issues between different stacks in the field.
> 
> I’m interested in the working the opinion of the TRAM experts on this topic.
> 
> Best regards
>   Nils Ohlmeier
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/tram&source=gmail-imap&ust=1614815933000000&usg=AOvVaw1n1YAlhUsnhlTcx1V3NGXC