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

[Eric Rescorla <[e-mail]>]

On Wed, Jan 16, 2019 at 4:15 PM Sebastian Kiesel <[e-mail]>
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
>