Re: [tram] Contradictions in RFC8489

Nils Ohlmeier <nohlmeier@mozilla.com> Thu, 25 February 2021 16:12 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 19E943A1BAE for <tram@ietfa.amsl.com>; Thu, 25 Feb 2021 08:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 W4qiOkdkSulE for <tram@ietfa.amsl.com>; Thu, 25 Feb 2021 08:11:59 -0800 (PST)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 D21193A1BAC for <tram@ietf.org>; Thu, 25 Feb 2021 08:11:58 -0800 (PST)
Received: by mail-qt1-x831.google.com with SMTP id c1so4466175qtc.1 for <tram@ietf.org>; Thu, 25 Feb 2021 08:11:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=iYMAnkrY/v9uRw9R/AkDbxD7Wv5DGc2Iu1ZriV8rfs8=; b=giCBuBK6LIKl5Me7EoUf5am0bcpWCs2nqO87zcgMuNru23pDK63K9XVSpWWTvUPgFd 0YPnk9vOiRDu2Zcoo9qQZdcC7t7+lbL6LkexYPwDmwa7pxaToVFMwRH8J9mPvKeiFneP HniVf1+5ZgzTysPVUi/1lAxaMSHY7Yq9PwKsU=
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:references:in-reply-to:date :message-id:subject:to:cc; bh=iYMAnkrY/v9uRw9R/AkDbxD7Wv5DGc2Iu1ZriV8rfs8=; b=rO8ufZivScaGrYZ6cM/VnPkr3UeUAlu17e06JBoXn2gHSna3PcrHoud+N75+UkH/go zJwBXagit8nEMRfpxx31ZIDxRUpGmUucoWL0B0+lAtWOf4wpt7veI9FaLbSb2H+FOyF1 legZvsqRDNRchkoQWtkzIrhW89CBioT0a50l4cslTPOzh/ApDvxQIIdov5o6+lQLbuY7 wagRFu2mo3lGrmN3b725cZrEmwknJGnb3eaxwPHgKhGpEX9i/GpVLzqTNvwD71ANJ16d X+n7gNcTb4Iv7X8oRYE7HkDwXO6yUnynggtoBQYcn5ifYFTNu4TwRxUx/7wKZb8pwWi7 Ba0Q==
X-Gm-Message-State: AOAM533gzH47P8vOqaQBOU04H+bZYgvaHQt7ToLlDAPgDvpbTkEfsBVc FN5eUVcgjeAzYQSBH7KZ7DItvNoSPMDfnjlYjCyBcA==
X-Google-Smtp-Source: ABdhPJw5ragP+AECBw/XTiPewt+Ck9A3Aa4cZpD5DUVBcEn7sHrJgD4+3U6GtixBlsQcWshN3580FPeELSbvbxWAI+g=
X-Received: by 2002:ac8:5bd1:: with SMTP id b17mr3037272qtb.53.1614269517274; Thu, 25 Feb 2021 08:11:57 -0800 (PST)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Thu, 25 Feb 2021 16:11:56 +0000
From: Nils Ohlmeier <nohlmeier@mozilla.com>
Mime-Version: 1.0 (1.0)
References: <D47E7EAD-0386-45FD-B51B-46621976009D@logmein.com>
In-Reply-To: <D47E7EAD-0386-45FD-B51B-46621976009D@logmein.com>
Date: Thu, 25 Feb 2021 16:11:56 +0000
Message-ID: <CANKS34du_xO9hpbxQxt1vTO7DzYV8RLszxHTon5sGGGypROkjA@mail.gmail.com>
To: Simon Perreault <Simon.Perreault@logmein.com>
Cc: tram@ietf.org
Content-Type: multipart/alternative; boundary="000000000000263e0805bc2b69cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/X3NlLXQt_wdUBQ8HCoEJYM_TLKo>
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: Thu, 25 Feb 2021 16:12:01 -0000

Since I’m not on the TURN server side I don’t know about their reasons to
deploy their service without message integrity.
What I can say though is that the ICE of one browser accepts 300 responses
without message integrity. This might have influenced how services design
their server side systems.

Best
  Nils

Am 2/25/21 um 04:48 schrieb Simon Perreault <Simon.Perreault@logmein.com>om>:

 Nice catch!

Could it be that the use cases hinted at are some kind of anycast support
where the anycast address redirects to a unicast address?

15 <https://tools.ietf.org/html/rfc8489#section-15>.  Operational Considerations

   STUN MAY be used with anycast addresses, but only with UDP and in
   STUN Usages where authentication is not used.


Simon

On Feb 24, 2021, at 6: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
<https://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-10__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11MC7o-O3$>
 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc8489*section-14.8__;Iw!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11DOQq0dJ$>
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

_______________________________________________
tram mailing list
tram@ietf.org
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tram__;!!OA8L0MA-!t2G-kDCvHfAAn7R3L64PHZCuQ7azwv5ENaWNgDupXoSN2whDUFcrtyxIkxG11Em3cMtH$