Re: [tram] Contradictions in RFC8489

Dan Wing <danwing@gmail.com> Sun, 28 February 2021 01:49 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 49C453A17D3 for <tram@ietfa.amsl.com>; Sat, 27 Feb 2021 17:49:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 QlNXiifBXc4r for <tram@ietfa.amsl.com>; Sat, 27 Feb 2021 17:49:23 -0800 (PST)
Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 3D83C3A17D2 for <tram@ietf.org>; Sat, 27 Feb 2021 17:49:23 -0800 (PST)
Received: by mail-pl1-x634.google.com with SMTP id d11so7412622plo.8 for <tram@ietf.org>; Sat, 27 Feb 2021 17:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WYouX9VKwMt26f2r+8IZje/SelDOhNCHR3uQQ946PGw=; b=Q6egsxIJtTmdD/YzqUh/+vEZ3/z0KZos5Fc/qCi/s3tP1yCmfz3hnO5ujLklbsAe+P ZU1xUSoXzZFdNK4C+BTuAjUh1w/b8z4Zytry2x3ixJEDHerQKvsGdFb15h3LX0dtPZHI Td2i9DMMlCeVc4i4sbOTc6CKsaF7d/JsfKJFBLfgu58rHZeGhzqQV1zlzFpwBlVZykdf Ii0S7rz7uXWi7seN4GDXwIrqMg8cWH5rFThU3qeTfgRAFrxig3CCaOpinNG1jJZNOWW4 5O44aSxtTqfkKDy0V8eJqbaSElihJTdp3+giOQfH/QJ0E5poetLYEz8NkgtvfWg4DDvM J3Xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=WYouX9VKwMt26f2r+8IZje/SelDOhNCHR3uQQ946PGw=; b=kzEQD4Q+0PUKaDJjcDxm9wAzRhC5EhOixaPIvZAQshSUjGfhjW/N4OZhJPiHJWNbrU t7JsG/KnUlGmjvgY8pkjFvj6BYtZezlKuLgKAG0gs5rfQF3Cw+Qjub5u/Epen/it9Vjy mxscvLiORmunSh9OAWq0lPbdNEpgYIkXmMQrjR2wijZ+PgRjgF6HYm+UGgFB++p/Iw34 SJ/AhWooEuQN9qKybfOU84xDVIhQ8aaVLaCRIR/9819JUZ/3vge2QHyPn2TWJmT24iiG NrUAAYzsAT1+8d5ay+QzirNHxWfwQQZiDzncGXRZxg/xGWfE8H4jgKemB/pQKXI/B3jh FoFw==
X-Gm-Message-State: AOAM5301e+m/fYAk60jU1av3Hgveht17j/TJU7Fcil+UZvSdYasD0uL2 q9Z7S/lIoQHvdL+UVOGNM++E1kyXwRU=
X-Google-Smtp-Source: ABdhPJwL3TKNNH8mxqAN5CxKg15+DlJaugUzzQGSUMBEUIxA50PyE0dW2yNrx25CReiF+fOewieenQ==
X-Received: by 2002:a17:902:cece:b029:e4:89af:adf with SMTP id d14-20020a170902ceceb02900e489af0adfmr4123214plg.53.1614476962643; Sat, 27 Feb 2021 17:49:22 -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 w13sm18326687pjg.0.2021.02.27.17.49.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 27 Feb 2021 17:49:22 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
From: Dan Wing <danwing@gmail.com>
In-Reply-To: <VI1PR01MB3008208EA6E4C9B9BA674B1AB19C9@VI1PR01MB3008.eurprd01.prod.exchangelabs.com>
Date: Sat, 27 Feb 2021 17:49:20 -0800
Cc: Nils Ohlmeier <nohlmeier@mozilla.com>, "tram@ietf.org" <tram@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3710943A-50EC-42C5-B72D-5349B8C3FEE1@gmail.com>
References: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com> <924F7C3A-B9A5-4648-ADC2-704EF78B8698@gmail.com> <VI1PR01MB3008208EA6E4C9B9BA674B1AB19C9@VI1PR01MB3008.eurprd01.prod.exchangelabs.com>
To: Karl Stahl <karl@ingate.com>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/AOs_j58rfGrPMnwtiu9PXNJN11Q>
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: Sun, 28 Feb 2021 01:49:25 -0000

Alt-Server was contentious during standardization because an attacker can send legitimate traffic towards a victim -- much like an ICMP redirect (which is also unauthenticated).  The active discussions probably led to the contradictory text and, yet, implementations still need to do what they do.  Perhaps we need to refine text for an errata, or consider an updated RFC to clarify Alt-Server.

-d


> On Feb 26, 2021, at 8:46 PM, Karl Stahl <karl@ingate.com> wrote:
> 
> Hi from Karl at Ingate & Intertex,
>  
> When used for auto discovery of a an enterprise turn server (on the LAN or in the access network), you typically don’t have any credentials and are talking clear text, but still get the 300 response, so there a non-authenticated 300 response must be allowed.
>  
> So this text is simply TOO STRICT and should be released:
> 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
>  
> /Karl
>  
> Från: tram <tram-bounces@ietf.org> För Dan Wing
> Skickat: Friday, 26 February 2021 20:37
> Till: Nils Ohlmeier <nohlmeier@mozilla.com>
> Kopia: tram@ietf.org
> Ämne: Re: [tram] Contradictions in RFC8489
>  
> 
> 
> 
> 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