Re: [alto] Eric Rescorla's Discuss on draft-ietf-alto-xdom-disc-04: (with DISCUSS and COMMENT)
"Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net> Fri, 18 January 2019 10:12 UTC
Return-Path: <ietf@kuehlewind.net>
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 C501113117E; Fri, 18 Jan 2019 02:12:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=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 9J0zBY0wH90t; Fri, 18 Jan 2019 02:12:43 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 42B18130F3C; Fri, 18 Jan 2019 02:12:43 -0800 (PST)
Received: from ict-networks-2001-067c-10ec-5785-8000-0000-0000-0430.fwd-v6.ethz.ch ([2001:67c:10ec:5785:8000::430]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1gkR8b-0002Aa-S1; Fri, 18 Jan 2019 11:12:33 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: "Mirja Kuehlewind (IETF)" <ietf@kuehlewind.net>
In-Reply-To: <CABcZeBOvfLOuRFWBOgy0kUOXJCWZRyxWgOcGT0dzNAoxdRL2Qg@mail.gmail.com>
Date: Fri, 18 Jan 2019 11:12:32 +0100
Cc: alto-chairs@ietf.org, draft-ietf-alto-xdom-disc@ietf.org, alto@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FE0D8F3-7CA4-4C18-8190-8B33DAF837A7@kuehlewind.net>
References: <154525256270.1869.17615446140661969035.idtracker@ietfa.amsl.com> <20190117001502.6lgdivbn32mn6jxa@gw01.ehlo.wurstkaes.de> <CABcZeBOvfLOuRFWBOgy0kUOXJCWZRyxWgOcGT0dzNAoxdRL2Qg@mail.gmail.com>
To: Sebastian Kiesel <ietf-alto@skiesel.de>
X-Mailer: Apple Mail (2.3445.9.1)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1547806363;67de4c76;
X-HE-SMSGID: 1gkR8b-0002Aa-S1
Archived-At: <https://mailarchive.ietf.org/arch/msg/alto/vCOkmaVklfcMIGUQdHI-9zirZ4w>
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: Fri, 18 Jan 2019 10:12:48 -0000
Hi Sebastian, so to summarize I think what’s needed is some discussion about what can happen if DNSSEC is not used and maybe even a requirement that certain data MUST be integrity protected. I think that could also address Benjamin’s discuss. Can you maybe propose some new/additional text for the security consideration section and see if we can first address Ekr discuss and then start a conversation with Benjamin? Thanks! Mirja > Am 17.01.2019 um 14:42 schrieb Eric Rescorla <ekr@rtfm.com>: > > > > On Wed, Jan 16, 2019 at 4:15 PM Sebastian Kiesel <ietf-alto@skiesel.de> wrote: > 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)? > > The minimum obligation from 3552 is to document the security > properties of your protocol adequately, given that you're not requiring > DNSSEC (or even DoH). Given that you don't require this, the > 3552 analysis needs to be undertaken under the the assumption > that the attacker completely controls DNS and then work through > the consequences. > > > To my understanding, RFC2119 keywords are mainly used to ensure > interoperability between implementations. > > We routinely require that protocols have some sort of security mechanism > or only run over secure transports, > > > 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? > > Well, DoH doesn't provide the same security properties as DNS and the > integrity property is quite important here. But you're not requiring *any* > form of DNS security. > > > > > 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's part of a system which does and you're describing the overall properties of that system. > > I can live without the citation to 7525, but even as a descriptive matter, talking just about the CN is not a correct description of how HTTPS validation works. > > > > > 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. > > Which as far as I can tell, it does not do. > > > > 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? > > Instead of having this complicated fallback system, it seems like you could correctly > respond to most of these queries by having wildcards. This is just a comment. > > > > 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. > > All right. > > > > 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. > > What I'm asking for is to document the reasoning in this specification. > > > > 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. > > My point is that we regularly use STUN for things, so saying that you can't do X because it would require STUN is not a strong argument. > > -Ekr > > > ---------------------------------------------------------------------- > > 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 > _______________________________________________ > alto mailing list > alto@ietf.org > https://www.ietf.org/mailman/listinfo/alto
- [alto] Eric Rescorla's Discuss on draft-ietf-alto… Eric Rescorla
- Re: [alto] Eric Rescorla's Discuss on draft-ietf-… Sebastian Kiesel
- Re: [alto] Eric Rescorla's Discuss on draft-ietf-… Eric Rescorla
- Re: [alto] Eric Rescorla's Discuss on draft-ietf-… Mirja Kuehlewind (IETF)
- Re: [alto] Eric Rescorla's Discuss on draft-ietf-… Sebastian Kiesel
- Re: [alto] Eric Rescorla's Discuss on draft-ietf-… Mirja Kuehlewind (IETF)