From nobody Thu May 7 02:32:28 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ED71A006C for ; Thu, 7 May 2015 02:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=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 JvF-jJaWtcII for ; Thu, 7 May 2015 02:32:25 -0700 (PDT) Received: from jenni2.inet.fi (mta-out1.inet.fi [62.71.2.227]) by ietfa.amsl.com (Postfix) with ESMTP id 318881A0276 for ; Thu, 7 May 2015 02:31:33 -0700 (PDT) Received: from poro.lan (80.220.64.126) by jenni2.inet.fi (8.5.142.08) (authenticated as stenma-47) id 552B87C902D8900E; Thu, 7 May 2015 12:31:32 +0300 From: Markus Stenberg Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Thu, 7 May 2015 12:31:30 +0300 Message-Id: To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) X-Mailer: Apple Mail (2.2098) Archived-At: Cc: Markus Stenberg Subject: [dnssd] Review comments on hybrid-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 09:32:27 -0000 Section 2 seems to turn from terminology to something quite different; = perhaps new section header is needed? Section 3.2: I am not sure what=E2=80=99s up with A/AAAA magic handling - it seems = weird to me, and I am just brutally using UTF-8 for everything. It is a = MUST though, so I guess I have to live with breaking the draft = compatibility (or actually care and fix it :-p). Section 3.5+: I would remove the LLQ reference and just make more generic description = which both LLQ and push would fill. Section 3.5: Also, I would add logic to CF based RR handling; those can be answered = immediately if in cache, or if received (that=E2=80=99s what our = implementation does at any rate). I am not sure I am too happy with 10 second default TTL for non-LLQ = client case. Also the whole =E2=80=99three times=E2=80=99 sounds highly suspicious to = me; why? Client probably sends later requests in any case (and there is = no e.g. retry delay specified; is it just supposed to send 3 multicasts = immediately? or what? hmm). Cheers, -Markus From nobody Sun May 10 14:08:55 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD12B1A92BB for ; Sun, 10 May 2015 14:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 OfhxnnT5McYi for ; Sun, 10 May 2015 14:08:52 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (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 439C31A1B7A for ; Sun, 10 May 2015 14:08:52 -0700 (PDT) Received: by qgej70 with SMTP id j70so59555385qge.2 for ; Sun, 10 May 2015 14:08:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=jgQLWXfDhQkih5whcvchdBuyp/Squ0hpGmColUswI+0=; b=G+75dH3etDaY23gJbrp0OwqlJbEh4sGWY9KOqdH+ZgX7Rub9xJnsX4owrWMoZuwkm1 Gf975g90YX9usuZQlZZiTtKdLMYCffLiQzIK6Az/YVkeSstgN0j1NneutQUSzXR06++9 pcStmKQ8nt5js6cp1oVY7lr9ifaQ//RJQXrc0Wwij26HumtqR5FG2iG0uZHdXS/5huw0 Xpe3o3pF0S4u7DqDzNM238pUi3HalR6rDmg9lG+WjCG0dmOKHn+h3W/lOQJUdCJxfH9n jG2ppuzBxDYoZBRrLMysFvBQHQt4boUJYqLvwVEnXcQqpRXWtIIUtZpj0FY5qLrdBHXT 8dQA== X-Received: by 10.140.95.208 with SMTP id i74mr9620928qge.51.1431292131532; Sun, 10 May 2015 14:08:51 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 67sm8853535qhw.43.2015.05.10.14.08.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 14:08:50 -0700 (PDT) Message-ID: <554FC8E0.1060301@gmail.com> Date: Sun, 10 May 2015 14:08:48 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: ietf dnssd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dnssd] updated the mdns xlink draft review of security concerns X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 21:08:54 -0000 Dear dnssd wg, I have updated the mdns xlink draft review of security concerns related to existing proposals for solving bridge/wifi limitations with mDNS in campus or enterprise environments. Examples illustrating security issues as well exploitation methods were provided. https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-05 Regards, Douglas Otis From nobody Sun May 10 14:27:58 2015 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CAB1AC3E0 for ; Sun, 10 May 2015 14:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 y00Mrug556FN for ; Sun, 10 May 2015 14:27:55 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 41B7F1AC3D7 for ; Sun, 10 May 2015 14:27:55 -0700 (PDT) Received: by qkx62 with SMTP id 62so76728220qkx.0 for ; Sun, 10 May 2015 14:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=6H/BJqUqquQ/7jM46mHLMMxNBrAdWbwVR2s1yMRjNY0=; b=ShmW8paYsdrRMAtFcpOyYUKNlg3MwNrGW99lMfbmKjYI6Q9G55bF1S6tk519YQo39H C8gLN04z34dnqd1DcyWzpu4QgACOLisrFriumfC4wH1SuGxlf4aWEMvYt5rX6ujNE3Hq TOSQE2gmif+Bxv2dzpfvwveMGCopv3VKHaMIhpXpKSOafZw7d1YHvQEDKqgVbf1UYqPa W+qGPN/p9wb7B23t34sxumSKJWKP7zpXxC+jHZ6VOGf9Xp1mOsz7g2qFqz2PFlB3lW0N 9/A+ZE7paKBP6BEO5VURSOOFS+XZhjgP5d7sY1JoPLT4NaED5sFeQVXoCQ58zlr/FWFp Dh/Q== X-Received: by 10.55.25.5 with SMTP id k5mr16120128qkh.35.1431293274589; Sun, 10 May 2015 14:27:54 -0700 (PDT) Received: from US-DOUGO-MAC.local (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id e70sm8886244qka.40.2015.05.10.14.27.53 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 May 2015 14:27:53 -0700 (PDT) Message-ID: <554FCD58.1050100@gmail.com> Date: Sun, 10 May 2015 14:27:52 -0700 From: Douglas Otis User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: dnssd@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dnssd] Multicast DNS (mDNS) Threat Model and Security Consideration X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2015 21:27:57 -0000 On 4/15/15 1:34 AM, Albrecht, Harald wrote: > Another thing that strikes me is the use of "GUA address" and "ULA address". The "A" in "GUA" and "ULA" already means address, so "GUA address" basically means a "global unicast address address". Either a sole "GUA"/"ULA" is already sufficient or always spell "global unicast address" in full. > > With respect to section 3.7.1 "Storing mDNS names in unicast DNS" I wonder if there are attacks possible based on leaking UTF-8 labels into unicast DNS and thus upsetting either DNS servers, (stub) resolvers, and IDNA libraries? > > In section 3.13.4.1 what is the security standpoint rationale to not publish GUAs? For instance, if a site decides to not use ULAs but only GUAs (believe me, there are such huge sites in IPv4 that run their company intranet on global addresses, not on private ones) then this would not be less secure than using ULAs. Some moments before the draft argues with respect to ULA accessibility. The same also applies to GUAs. Not publishing something doesn't mean it's not reachable - this would be a perfect example of security by obscurity. And security by obscurity is known to not offer any security at all. So, please detail the rationale behind 3.13.4.1 and it focusing on ULA only. > Dear Harald, https://tools.ietf.org/html/draft-otis-dnssd-mdns-xlink-05#section-3 attempts to clarify differences between GUA and ULA based on the definition by https://tools.ietf.org/html/rfc4193#section-3.2 An addendum was added to better illustrate the risks. Notes collected in creation of https://www.kb.cert.org/vuls/id/550620 also clarifies addition threats. Somehow the cert link failed to expand properly. Will fix, but Google will also resolve based on the link title. Regards, Douglas Otis