Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sun, 09 September 2018 01:52 UTC

Return-Path: <kaduk@mit.edu>
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 90D1A130DCC; Sat, 8 Sep 2018 18:52:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 NshvDIVq1THW; Sat, 8 Sep 2018 18:52:50 -0700 (PDT)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D503E12D7F8; Sat, 8 Sep 2018 18:52:49 -0700 (PDT)
X-AuditID: 1209190e-3fbff70000004c8f-80-5b947cefe1c0
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.36.19599.0FC749B5; Sat, 8 Sep 2018 21:52:48 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w891qgrT004655; Sat, 8 Sep 2018 21:52:43 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w891qWX5021230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 8 Sep 2018 21:52:37 -0400
Date: Sat, 8 Sep 2018 20:52:32 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Marc Petit-Huguenin <marc@petit-huguenin.org>
Cc: Adam Roach <adam@nostrum.com>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>, The IESG <iesg@ietf.org>, tram-chairs@ietf.org, draft-ietf-tram-stunbis@ietf.org, Tolga Asveren <tasveren@rbbn.com>, tram@ietf.org
Message-ID: <20180909014711.GT73164@kduck.kaduk.org>
References: <152403138853.31946.14807823535362928987.idtracker@ietfa.amsl.com> <27cb2f70-d907-b61f-bb5a-6b19053238fe@petit-huguenin.org> <1e8cd5de-06de-6745-fc4d-d15fcdd0b4d9@petit-huguenin.org> <df27ff82-bb5a-8c83-f119-a6f4e9f65a53@nostrum.com> <a5da7dc3-472c-8dcf-27e0-7e334d6590f6@ericsson.com> <5ff10fb0-301e-5d97-01b0-f15296bae0d3@nostrum.com> <b845eb08-7974-ec9d-0a98-e04d6071b2e1@petit-huguenin.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <b845eb08-7974-ec9d-0a98-e04d6071b2e1@petit-huguenin.org>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsUixG6novuhZkq0wZk9ihZ7/i5it+jccpnN YtPylUwWM/5MZLZYe/wmo8X65d/YLZb/XMlm8WHtBTYHDo9fX6+yeSxZ8pPJY9bOJywex09f Z/XYM2cSYwBrFJdNSmpOZllqkb5dAlfGkkNX2At6rCuWNSxmbWB8r9fFyMkhIWAi0fziEWsX IxeHkMBiJonT3buYIZwNjBKf3h1ig3CuMEnsef2QCaSFRUBF4tOraywgNhuQ3dB9mRnEFhEw lDi/6DpYN7PAX0aJL9t+soEkhAVSJI4+mADWzAu0r/NKOzvE1EXMEre2nWSBSAhKnJz5BMxm FtCR2Ln1DlAzB5AtLbH8HwdEWF6ieetssGWcAm4SfyY+AisXFVCW2Nt3iH0Co+AsJJNmIZk0 C2HSLCSTFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11svNLNFLTSndxAiKGk5Jvh2Mkxq8 DzEKcDAq8fCe4J4SLcSaWFZcmXuIUZKDSUmUN0d/crQQX1J+SmVGYnFGfFFpTmrxIUYJDmYl Ed7z34FyvCmJlVWpRfkwKWkOFiVx3rO6QCmB9MSS1OzU1ILUIpisDAeHkgTv5wqgPYJFqemp FWmZOSUIaSYOTpDhPEDDL4LU8BYXJOYWZ6ZD5E8x6nL8eT91ErMQS15+XqqUOG87SJEASFFG aR7cHFCyk8jeX/OKURzoLWHe+kqgKh5gooSb9ApoCRPQEmE9kA+KSxIRUlINjLtXFO7YVrjs Q0jdvYWTv57cqPtqwsp6pn03fCba3y/juCgmu8VtlvWZAt9eM/e6A7Mjg6Yt1YhZp/t2Bq/l ttQXPftbsu/nF2yzWbzCTzLkgMxCX4NAdoOW3+WLOBO2HVo4o8//+0fXm8HyYi94lReu8dMQ Y1z6t+2egKOscpRCnhT7u2MiQkosxRmJhlrMRcWJAF5/BuRRAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/UGRq_UJ017uQav3ml-VJWe7KVtI>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stunbis-16: (with DISCUSS and COMMENT)
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, 09 Sep 2018 01:52:53 -0000

Hi Marc,

On Sat, Sep 08, 2018 at 02:59:41PM -0700, Marc Petit-Huguenin wrote:
> Hi Adam,
> 
> Apologies for the delay in working on that.
> 
> For the first issue, the fix is in my copy of the draft.
> 
> As for the second issue, Section 8.1 says:
> 
> 'A "stuns" URI
>  containing an IP address MUST be rejected, unless the domain name is
>  provided by the same mechanism that provided the STUN URI, and that
>  domain name can be passed to the verification code.'
> 
> That text was never about IP addresses in certificates, but about the way a STUN (or TURN really, but that draft does not care about TURN) server IP address is passed to a WebRTC browser.  RFC 7064 permits to store an IP address directly inside a stun URI, and RFC 7350 extended that to stuns URI, and in fact the text above is directly copied from RFC 7350.
> 
> The idea is that a stun URI can be provisioned by a JavaScript program
> downloaded by a WebRTC browser as part of the initialization of a WebRTC
> application.  A security assumption is that using a stuns URI that
> contains an API address is safe if the Javascript program was downloaded
              ^^^
(I assume this is autocorrect picking the wrong thing to fix a typo and
should be "IP Address")

> using https, that the hostname verification for the https certificate
> implies that the stuns URI embedded in the document are receiving
> adequate protection and can be used without worrying about the lack of
> certificate verification for the stuns URI.
>
> Now that is an assumption that we made, and we'd very much like to hear
> if that assumption is incorrect.

Note that I may be lacking full context, but based just on your description
above and § 8.1 of the -18, I am concerned about your statement "without
worrying about the lack of certificate verification for the stuns URI".  My
understanding is, that given a stuns URI with an IP address for the host
and some domain name specified by the same mechanism that provided the URI,
is that this domain name would then be used as input to the servername
verification process for the new connection using this stuns URI.  Your
statement that I quote here makes it sound like no certificate verification
is done on this second connection, which would seem to make it vulnerable
to a MITM attack (and thus be a bad idea).

-Benjamin

> Section 6.2.3 is unrelated - it is about IP addresses provisioned locally (not received from the server), and a matching certificate containing IPAddress.  I'll make that more explicit after I receive your response on the subject above.
> 
> Also it seems that your DISCUSS is not related to that issue at all, would it be possible to clear it?
> 
> Thanks.
> 
> On 06/18/2018 10:45 AM, Adam Roach wrote:
> > Gonzalo:
> > 
> > TL;DR -- unless someone can find evidence indicating what the WG intended, I believe we are waiting on you and Simon.
> > 
> > I had two responses in my most recent message. I presume the first should be uncontroversial.
> > 
> > The second point pertains to how the working group intended to treat IP addresses in STUNS URIs. The document right now is ambiguous and self-contradictory. If this has been discussed in the past, then the document simply needs to be updated to reflect the outcome of that conversation. If not, then I believe the WG needs to have a conversation about what is intended.
> > 
> > As it stands, the document will lead to various notions about whether (and how) IP addresses can be used, which will be an interop nightmare.
> > 
> > /a
> > 
> > On 6/18/18 05:41, Gonzalo Camarillo wrote:
> >> Marc, Adam,
> >>
> >> what is the status of this discussion?
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >>
> >> On 21/05/2018 9:11 PM, Adam Roach wrote:
> >>> Sorry for taking so long to get back to you on this. Two responses below
> >>> -- everything else looks good.
> >>>
> >>> On 5/3/18 6:37 PM, Marc Petit-Huguenin wrote:
> >>>> On 04/23/2018 03:37 PM, Marc Petit-Huguenin wrote:
> >>>>>> ---------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>> §17.3.1:
> >>>>>>
> >>>>>>>    IANA is requested to update the names for attributes 0x0002, 0x0003,
> >>>>>>>    0x0004, 0x0005, 0x0007, and 0x000B, and the reference from RFC 5389
> >>>>>>>    to RFC-to-be for the following STUN methods:
> >>>>>> ...
> >>>>>>>    0x0003: (Reserved; prior to [RFC5389] this was CHANGE-REQUEST)
> >>>>>> The attribute 0x0003 is registered by RFC 5780, and should not be
> >>>>>> removed by this document.
> >>>>> Fixed.
> >>>
> >>> Thanks for the change, but the new text still asks IANA to update the
> >>> table so that 0x0003 points to *this* document, instead of continuing to
> >>> point to RFC 5780. Since this document does not do anything with
> >>> CHANGE-REQUEST, this update does not seem correct.
> >>>
> >>>
> >>>>>> ---------------------------------------------------------------------------
> >>>>>>
> >>>>>>
> >>>>>> §6.2.3 says:
> >>>>>>
> >>>>>>>    Alternatively, a
> >>>>>>>    client MAY be configured with a set of IP addresses that are
> >>>>>>> trusted;
> >>>>>>>    if a certificate is received that identifies one of those IP
> >>>>>>>    addresses, the client considers the identity of the server to be
> >>>>>>>    verified.
> >>>>>> Presumably, this means the server supplies a certificate with
> >>>>>> SubjectAltName
> >>>>>> containing an iPAddress? Please add text to clarify whether that's the
> >>>>>> intention.
> >>>>>>
> >>>>>> If that *is* the intended meaning, then this behavior in §8.1 seems
> >>>>>> unnecessarily restrictive:
> >>>>>>
> >>>>>>>    A "stuns" URI
> >>>>>>>    containing an IP address MUST be rejected, unless the domain name is
> >>>>>>>    provided by the same mechanism that provided the STUN URI, and that
> >>>>>>>    domain name can be passed to the verification code.
> >>>>>> Presumably, this is done because certs with iPAddress-form
> >>>>>> SubjectAltNames are
> >>>>>> pretty rare (although CAB Forum baseline requirements do explicitly
> >>>>>> allow
> >>>>>> their issuance) -- but if the text in §6.2.3 is based on allowing
> >>>>>> the use of
> >>>>>> such certs in a TURN deployment, then it seems that URI resolution
> >>>>>> should be
> >>>>>> also.
> >>>>>>
> >>>>> I am not sure what was the intent there, so I'll work on that later.
> >>>> We addressed all the other comments, but it would be great if you
> >>>> could suggest some text to address that one.
> >>> I'm not sure what was meant either!
> >>>
> >>> I think we need to untangle what the working group meant to say
> >>> regarding "trusted IP addresses," the way this protocol is intended to
> >>> use certs, and whether the prohibition on using IP addresses in "stuns"
> >>> URIs derives from cert handling or if it has a completely different
> >>> rationale behind it; and, if the former, ensure that those things that
> >>> are prohibited or allowed in certs are similarly prohibited or allowed
> >>> in URIs.
> >>>
> >>> I can suggest some *behavior*, but unless there is some record of what
> >>> the WG meant, any such behavior would need to be discussed by the
> >>> working group, and a consensus would need to be declared by the chairs.
> >>>
> >>>
> >>> /a
> >>>
> > 
> 
> 
> -- 
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: https://marc.petit-huguenin.org
> Profile: https://www.linkedin.com/in/petithug
> 
> 
>