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 <[email protected]>: > > > > On Wed, Jan 16, 2019 at 4:15 PM Sebastian Kiesel <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/alto _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
