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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

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 <[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
> _______________________________________________
> alto mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto