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

Sebastian Kiesel <ietf-alto@skiesel.de> Thu, 17 January 2019 00:15 UTC

Return-Path: <sebi@gw01.ehlo.wurstkaes.de>
X-Original-To: alto@ietfa.amsl.com
Delivered-To: alto@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B31A126CC7; Wed, 16 Jan 2019 16:15:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 18.101
X-Spam-Level: ******************
X-Spam-Status: Yes, score=18.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, URIBL_BLACK=20] autolearn=no 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 0uUJZ5bDxL3k; Wed, 16 Jan 2019 16:15:15 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de (gw01.ehlo.wurstkaes.de [IPv6:2a02:a00:e000:116::41]) (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 C39BE12D4EF; Wed, 16 Jan 2019 16:15:14 -0800 (PST)
Received: from gw01.ehlo.wurstkaes.de ([2a02:a00:e000:116::41]:47850) by gw01.ehlo.wurstkaes.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <sebi@gw01.ehlo.wurstkaes.de>) id 1gjvKu-0001mG-RG; Thu, 17 Jan 2019 01:15:08 +0100
Date: Thu, 17 Jan 2019 01:15:02 +0100
From: Sebastian Kiesel <ietf-alto@skiesel.de>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, alto@ietf.org, Jan Seedorf <jan.seedorf@hft-stuttgart.de>
Message-ID: <20190117001502.6lgdivbn32mn6jxa@gw01.ehlo.wurstkaes.de>
References: <154525256270.1869.17615446140661969035.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <154525256270.1869.17615446140661969035.idtracker@ietfa.amsl.com>
Organization: my personal mail account
Accept-Languages: en, de
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: sebi@gw01.ehlo.wurstkaes.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/yFNEWBdoHR2E62MKPTLZ2f3jW6A>
Subject: Re: [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
Precedence: list
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: Thu, 17 Jan 2019 00:15:17 -0000

On Wed, Dec 19, 2018 at 12:49:22PM -0800, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-alto-xdom-disc-04: Discuss
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 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.

While I definitively understand your concern, I am not sure whether
you are implying a possible way forward.  Please clarify, does "and yet
it's not mandated." mean that we should use a MUST [RFC2119] to tell
network operators what to do (i.e., sign their in-addr.arpa. subdomain)?

To my understanding, RFC2119 keywords are mainly used to ensure
interoperability between implementations. An implementation of our
procedure will most likely make use of the operating system's
stub resovler and - technically - it will not care about which
underlying mechanism is used for the transport, including integrity and
confidentiality protection, of DNS queries and replies.

Using DNSSEC for the reverse zone seems like a very good idea at this
point in time (and it can be done - see at the end of this mail), but
given recent and onging developments such as DOH, is it wise to mandate
one specific mechanism, when we are only very loosely coupled to it?

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

ALTO servers will definitively give information beyond what we could put
in the DNS - otherwise we wouldn't need the ALTO protocol [RFC 7285].
Typical information could be processed information extracted from
routing tables, indicating the topological distances or "routing costs"
between any pairs of IP addresses.

Scenarios and risks related to unintended information disclosure through
ALTO have been discussed in detail in Section 5.2 of RFC 6708 (both
from the point of view of the publisher and the client sending queries).
Possible consequences of and mitigation strategies for wrong (forged)
ALTO information are discussed in Sections 15.1 and 15.2 of RFC 7285.

What this paragraph above wants to say is that an attack against the
integrity of the DNS could make these risks become a reality. 
However, the consequences described in the above-mentioned sections seem in
general - without knowing and analyzing the exact deployment 
scenario - rather limited and manageable compared to other risks that
may occur if we cannot trust integrity protection in our DNS
infrastructure.


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

The XDOM discovery procedure itself does NOT use HTTPS/TLS.  It uses
NAPTR lookups, which should be protected by DNSSEC or otherwise (see
above), and produces the (HTTPS-)URI of an ALTO server.  Once we have
learned that URI, we are in the domain of the ALTO protocol, i.e.,
RFC 7285, which contains guidelines how to use HTTPS and TLS.

What this paragraph wants to say is:  In the world wide web, when a user
enters a HTTPS URI into his browser, we can live quite well without
DNSSEC.  If the DNS gives a wrong A/AAAA record, we can detect it when
the server cert's CN is matched against what the user has entered.  This
won't work here - the NAPTR RRs must be authentic!

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

Protecting the exact query, after all an HTTP POST, is mainly covered in
RFC 7285.  XDOM disc just needs to make sure that an attacker cannot
redirect a client to the URI of a malicious ALTO server and do a MITM
attack even with TLS in place.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 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?

At the moment there is no further use case in the context of ALTO,
yet we don't want to hardcode "ALTO:https" in the procedure as
new applications could emerge within or outside of ALTO.

btw: We will remove the RFC 2119 keywords here, because they are
redundant to section 3.1.

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

sorry, I am not sure whether I understand this comment correctly.
Could you please be a bit more verbose here?

> 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: 240.255.255.255.in-addr.arpa,
> and then my next one should be 255.255.255.in-addr.arpa? Is that
> correct?
> 
> Where does the text say that I should zero the low-order bits in R32?

you will match /28 against the second column of the table and conclude
that the second row applies. Consequently, you MUST lookup R24 first and
then SHOULD try R16 and R8 until success.

in your example, R24 is 255.255.255.in-addr.arpa so it doesn't matter
whether or not you zero the 4 least significant bits first, they get
cut off anyway.

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

The number of truncate-then-try-lookup steps is a compromise between
flexibility for those who want to install such NAPTR RRs
and not causing excess load on the DNS in particular if no such NAPTR
RRs are present.

In the IPv4 case, an upper bound of 4 steps seems straightforward and
natural, due to the dotted quad notation.  We decided to use a similar
number (5) of steps also for IPv6. Maybe, one more step, for /40 would
make sense, so all steps truncate the same number of bits, but not
significantly more steps.  By no means does this scheme mean that we
assume or encourage address allocations following only these bit
boundaries!

btw: the same 5 lookup steps for IPv6 are specified in RFC 7216, which
has inspired our procedure.

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

Technically it would be possible, with some fine print about topology
awareness in scenarios with cascaded NATs etc.  We don't need it for our
scenarios. I forgot who talked us into citing RFC3424 quite some time
ago. For the sake of a more generally applicable procedure (see above)
we can remove the "NOT RECOMMENDED", if this is considered a good idea.

----------------------------------------------------------------------

example: R24 = 3.69.129.in-addr.arpa.

dig -t ANY 3.69.129.in-addr.arpa.

; <<>> DiG 9.10.3-P4-Debian <<>> -t ANY 3.69.129.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59261
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;3.69.129.in-addr.arpa.		IN	ANY

;; ANSWER SECTION:
3.69.129.in-addr.arpa.	600	IN	RRSIG	NAPTR 10 5 600 20190120142147 20190110132147 36896 69.129.in-addr.arpa. PjbZQVxia87jSlAn+kpKtYlqYBKZ1DOightrZf6ZmeHRvznJM6vPrInY zoBm1iEoi03JnTgAfhHs1hl0JLRDjD+xJRzDKn82PJVoUVV9m9H1HBbw RWkQgxB/xLmUMAlaVO6/URbOEKnfIYtXz5WsvT5I2udk2STWmJu/Vdoa mUP3SB5kvsAGkw6hwfPmc9M5NWAKeL49pPoaNFtA9KDlOIYmTXQ3OjCU pXhFgiNAx3hjgUFtk1fTo6iHaAYLROsMGnZjcBR/jW+NWRLhqKPuwUzf fMY7AvLSm7SiLyaKCPBjGJ2tO3iKWDNmvd3BK+TFbavLI3kDTcLydIq/ K2PFnDI1e0sW98pPKMy9epvpghy/h3gR8058DNpw5iU5xLbK72/5gf2D Tlt3oBqLm2t+T+2TzyVXByR4ZQQHuK2GearDZJqeXbCrznczVURPvWLU OOmCj67mlv/BicW7ToAvozv9OTs+j68eZbQHnPnTtDdUpD5bciwRhBBW r9FZgwqBLB7X82aZ4Pp6tqeSiqkZiWRZIIe3pFhGusOsI27UHH3VwRnp iUuYfVjyC5j75qd7zuf/azOEWMbdaVXFpwu7c0zAKWMx0Cl1sMM/+sj8 awpoG5zrLqkAu0hbj8huB0eZKIdC3p5G6+Bz4LAaDDpv0+Orvl1Up4SU buUfoOmjGpo=
3.69.129.in-addr.arpa.	600	IN	NAPTR	100 10 "u" "ALTO:https" "!.*!https://nks-devel3.rus.uni-stuttgart.de/alto/ird!" \"\".

;; Query time: 439 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jan 17 00:39:58 CET 2019
;; MSG SIZE  rcvd: 700