[tram] Contradictions in RFC8489

Nils Ohlmeier <nohlmeier@mozilla.com> Wed, 24 February 2021 23:58 UTC

Return-Path: <nohlmeier@mozilla.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 DC2943A1DBC for <tram@ietfa.amsl.com>; Wed, 24 Feb 2021 15:58:46 -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, HTML_MESSAGE=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 (1024-bit key) header.d=mozilla.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 CZxStP7LFAKV for <tram@ietfa.amsl.com>; Wed, 24 Feb 2021 15:58:45 -0800 (PST)
Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (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 E42AD3A1DBA for <tram@ietf.org>; Wed, 24 Feb 2021 15:58:44 -0800 (PST)
Received: by mail-pj1-x102f.google.com with SMTP id o6so2429659pjf.5 for <tram@ietf.org>; Wed, 24 Feb 2021 15:58:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:subject:message-id:date:to; bh=+q1yxWzUKQWc+aN7Iml8I1fMqJtoiGRtBSZ/4YfLDIM=; b=XfvzxVERNRSj0m+2leYE6cKisI8abAimyQ9f0FP5DWOXjpkiqHCLf304wg6jsx4TGg ABmXK/MAbzbRct7F3YMuYNafuwgSXdY4H3b7K37//e9WxPLuVXHSXc9BawAse2krUTwk z+65aKYx+wpSSfpXi4Zt93+bLe/lIi/YIZcqQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=+q1yxWzUKQWc+aN7Iml8I1fMqJtoiGRtBSZ/4YfLDIM=; b=d2MlghUdgY1vmlSMINlTVYhO2CmHPyXvnpLhgtLsltZqypjrzKv0tW1F5hcc4JgNMR y7AKnuk6TBZvOEWUbrNuJCUQdkWqbJQnLaMqvtTU3fHbc7XhnLnpH9LuQQW8Ralvovg8 2/XIqHrlXgEHI3muvb8XFRrI4tOqBDOnBVw0i4Uuvj7MUwFjSu1DqwyKZskzVUt3yQOp UzvApdz8harwUrXdld/VgFH7d4wOTHhdE9dWYvuCNqDNVHDGOZ+DOyOta60CPUVO/Ic4 rSR3wW2HJ+ZaFikzfrnKlBePi4ZQhKxazJdR0Dnv3Sh9/6FJyb8CXld1/3sxoFPPUS2j Nh0g==
X-Gm-Message-State: AOAM530/K87LmpgVyNhjqme0MSdUVntWbj81I40MGkyHtUa97nGiESuX D8ca1ahJuOCjdNkd3CAD1dHDzo9PyTxYJA==
X-Google-Smtp-Source: ABdhPJwxCuk4ptG6/B9cdtrprjPNHOQa2b9eYE/ZCT7YLTdfLONULL4GP1Ry3kSiycYZ3xiMxk9FBg==
X-Received: by 2002:a17:902:e750:b029:e3:a720:f4c with SMTP id p16-20020a170902e750b02900e3a7200f4cmr526295plf.31.1614211123865; Wed, 24 Feb 2021 15:58:43 -0800 (PST)
Received: from ?IPv6:2601:647:4600:3f31:e1:d945:2927:72ef? ([2601:647:4600:3f31:e1:d945:2927:72ef]) by smtp.gmail.com with ESMTPSA id x23sm3915838pff.133.2021.02.24.15.58.43 for <tram@ietf.org> (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Feb 2021 15:58:43 -0800 (PST)
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5A72FC42-5ACD-4D2A-8A25-E0BC0DFE76FF"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Message-Id: <2DB77788-814F-4F0D-AD42-B28126F1EFB8@mozilla.com>
Date: Wed, 24 Feb 2021 15:58:42 -0800
To: "tram@ietf.org" <tram@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/GaS8zpLBxIWEkhN9pWY_vGbZQtg>
Subject: [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: Wed, 24 Feb 2021 23:58:47 -0000

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