Re: [tram] Contradictions in RFC8489

Dan Wing <> Fri, 26 February 2021 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D20F73A15C3 for <>; Fri, 26 Feb 2021 11:36:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N4k4LWR59FwA for <>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29A4F3A15C1 for <>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
Received: by with SMTP id d12so4389022pfo.7 for <>; Fri, 26 Feb 2021 11:36:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 [] ( []) by with ESMTPSA id 2sm10041783pfi.116.2021. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 11:36:36 -0800 (PST)
From: Dan Wing <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BFCA44BA-A862-46BE-AC2C-C6732C411CB8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 26 Feb 2021 11:36:35 -0800
In-Reply-To: <>
Cc: "" <>
To: Nils Ohlmeier <>
References: <>
X-Mailer: Apple Mail (2.3654.
Archived-At: <>
Subject: Re: [tram] Contradictions in RFC8489
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 19:36:40 -0000

> On Feb 24, 2021, at 3:58 PM, Nils Ohlmeier <> 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 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 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
        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

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).


> 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