[alto] Eric Rescorla's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Wed, 19 December 2018 20:49 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: alto@ietf.org
Delivered-To: alto@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0A2130E86; Wed, 19 Dec 2018 12:49:22 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: "The IESG" <iesg@ietf.org>
Cc: alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, alto@ietf.org, Jan Seedorf <jan.seedorf@hft-stuttgart.de>, jan.seedorf@hft-stuttgart.de
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154525256270.1869.17615446140661969035.idtracker@ietfa.amsl.com>
Date: Wed, 19 Dec 2018 12:49:22 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/ytJlLvtITzsdIX6eeO97DWyOVhc>
Subject: [alto] Eric Rescorla's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/alto/>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Dec 2018 20:49:23 -0000

Eric Rescorla has entered the following ballot position for
draft-ietf-alto-xdom-disc-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Rich version of this review at:

The security considerations for this document don't seem to be
adequate. In general, the security of this mechanism seems to rely on
DNSSEC, and yet it's not mandated.

S 6.1.
>         However, it should also be noted that, if an attacker was able to
>         compromise the DNS infrastructure used for cross-domain ALTO
>         server discovery, (s)he could also launch significantly more
>         serious other attacks (e.g., redirecting various application
>         protocols).

Hmm... Are there no settings in which ALTO servers give information
that isn't something that is a subset of info in DNS? This seems like
it needs more analysis.

S 6.1.
>         certificate will contain the host name (CN).  Consequently, only
>         the host part of the HTTPS URI will be authenticated, i.e., the
>         result of the ALTO server discovery procedure.  The DNS/U-NAPTR
>         based mapping within the cross-domain ALTO server discovery
>         procedure needs to be secured as described above, e.g., by using
>         DNSSEC.

This is not an acceptable description of how to use TLS. Given that
you are using HTTPS, you need to cite 2818. And as this is a new
application of HTTPS, you should be specifying modern TLS, i.e.,
mimimum 1.2 and 7525.

S 6.4.
>         statement [RFC5693] and/or discussed in the ALTO working group,
>         this scenario has not been identified as a relevant threat.
>      Protection Strategies and Mechanisms
>         No protection mechanisms for this scenario have been provided, as
>         it has not been identified as a relevant threat.  However, if a

Another threat here is the disclosure of the exact query you are
making to the ALTO server. An attacker might be interested in that,
and it's not all manifest in the DNS query.


S 2.
>      The service parameter SHOULD always be set to "ALTO:https".  However,
>      other parameter values MAY be used in some scenarios, e.g.,
>      "ALTO:http" to search for a server that supports unencrypted
>      transmission for debugging purposes, or other application protocol or
>      service tags if applicable.

What would be applicable here?

S 2.
>      The discovery procedure sequentially tries two different lookup
>      strategies: First, an ALTO-specific U-NAPTR record is searched in the
>      "reverse tree", i.e., in subdomains of in-addr.arpa. or ip6.arpa.
>      corresponding to the given IP address or prefix.  If this lookup does
>      not yield a usable result, the procedure tries further lookups with
>      truncated domain names, which correspond to shorter prefix lengths.

Seems like wildcards could get a lot of this, no?

S 3.4.
>      | IPv4       |        32  |  R32       | R24, R16, R8               |
>      | IPv4       |  24 .. 31  |  R24       | R16, R8                    |
>      | IPv4       |  16 .. 23  |  R16       | R8                         |
>      | IPv4       |   8 .. 15  |   R8       | (none)                     |
>      | IPv4       |   0 ..  7  | (none, abort: invalid prefix length L)  |
>      +------------+------------+------------+----------------------------+

I'm trying to work out how this works. Say that AT=IPv4 and L=27, so
we have like ff.ff.ff.ff/28 (I know this is illegal, but it saves me
on math). My first look up should be:,
and then my next one should be 255.255.255.in-addr.arpa? Is that

Where does the text say that I should zero the low-order bits in R32?

S 3.4.
>      | IPv6       | 64 (..127) |  R64       | R56, R48, R32              |
>      | IPv6       |  56 .. 63  |  R56       | R48, R32                   |
>      | IPv6       |  48 .. 55  |  R48       | R32                        |
>      | IPv6       |  32 .. 47  |  R32       | (none)                     |
>      | IPv6       |   0 .. 31  | (none, abort: invalid prefix length L)  |
>      +------------+------------+------------+----------------------------+

What's the reasoning for this pattern?

S 5.1.1.
>      mechanisms such as STUN [RFC5389] would be needed and considerations
>      for UNSAF [RFC3424] apply.  Therefore, using the procedures specified
>      in this document for resource consumer based ALTO server discovery is
>      generally NOT RECOMMENDED.  Note that a less versatile yet simpler
>      approach for resource consumer initiated ALTO server discovery is
>      specified in [RFC7286].

Why can't people do STUN?