From owner-freebsd-current@FreeBSD.ORG Thu Sep 12 03:18:18 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id CEAFCB75; Thu, 12 Sep 2013 03:18:18 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by mx1.freebsd.org (Postfix) with ESMTP id 4DCD92A77; Thu, 12 Sep 2013 03:18:17 +0000 (UTC) X-AuditID: 12074422-b7ef78e000000935-35-523132729b94 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id 96.FA.02357.27231325; Wed, 11 Sep 2013 23:18:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id r8C3IAV8000969; Wed, 11 Sep 2013 23:18:10 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id r8C3I7vR009134 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 11 Sep 2013 23:18:09 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id r8C3I5vi010679; Wed, 11 Sep 2013 23:18:05 -0400 (EDT) Date: Wed, 11 Sep 2013 23:18:05 -0400 (EDT) From: Benjamin Kaduk To: Ian Lepore Subject: Re: HEADS UP: OpenSSH with DNSSEC support in 10 In-Reply-To: <1378913151.1111.613.camel@revolution.hippie.lan> Message-ID: References: <86hadre740.fsf@nine.des.no> <1378913151.1111.613.camel@revolution.hippie.lan> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1512555890-1378955885=:16692" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42IR4hRV1i02MgwyeMlnMeHKDyaLnk1P2Cye HH/D7MDsMePTfJYAxigum5TUnMyy1CJ9uwSujAO9a5gK9nFXnPjwmKmBcSVnFyMnh4SAicTC czfYIGwxiQv31gPZXBxCAvsYJa73z2eEcDYySuy50Q/lHGKSuLakF8ppYJTYvXM/K0g/i4C2 xOnzSxlBbDYBFYmZbzaCzRURUJDYMm81cxcjBwezgKnE1GOFIKawgIVEw/wSkApOATuJR8s+ MIPYvAKOEidXLAebKCQQJfFwQRvYRFEBHYnV+6ewQNQISpyc+QTMZhYIlDjT/4tpAqPgLCSp WUhSELa1xIa3U6FsbYn7N9vYFjCyrGKUTcmt0s1NzMwpTk3WLU5OzMtLLdI11cvNLNFLTSnd xAgKa3YXpR2MPw8qHWIU4GBU4uHtmGUQJMSaWFZcmXuIUZKDSUmUt1zbMEiILyk/pTIjsTgj vqg0J7X4EKMEB7OSCO+tf0DlvCmJlVWpRfkwKWkOFiVx3vVO+kFCAumJJanZqakFqUUwWRkO DiUJ3kxDoKGCRanpqRVpmTklCGkmDk6Q4TxAw+eD1PAWFyTmFmemQ+RPMSpKifNWgSQEQBIZ pXlwvbC084pRHOgVYd5ikCoeYMqC634FNJgJaPB3X32QwSWJCCmpBkY50T6FK1esu053PXA6 +2RxOPd+lrjljueWfj/1d8VLnS0/ZWe/nehdamhXOv1w8b3Ha+wtOy7xTy1Y/q5T5PSU319n TRPU+HIl2eN0c+Ht6b3mav1Wc0KfVR3wmNE48WthdKtmfFCT5gZxlxDHQqOMC1GJMVc5Vij6 OrNs2/65N1T627P8hAYlluKMREMt5qLiRAC2dNgkFgMAAA== Cc: freebsd-security@freebsd.org, current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Sep 2013 03:18:19 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1512555890-1378955885=:16692 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Wed, 11 Sep 2013, Ian Lepore wrote: > On Wed, 2013-09-11 at 17:00 +0200, Dag-Erling Sm=F8rgrav wrote: >> OpenSSH in FreeBSD 10 is now built with DNSSEC support, unless you >> disable LDNS in src.conf. If DNSSEC is enabled, the default setting for >> VerifyHostKeyDNS is "yes". This means that OpenSSH will silently trust >> DNSSEC-signed SSHFP records. I consider this a lesser evil than "ask" >> (aka "train the user to type 'yes' and hit enter") and "no" (aka "train >> the user to type 'yes' and hit enter without even the benefit of a >> second opinion"). >> >> DES > > So what happens when there is no dns server to consult? Will every ssh > connection have to wait for a long dns query timeout? There is a long precent for ssh waiting on DNS timeouts, with the GSSAPI*= =20 options. At least in some cases, ssh could end up waiting for 3 retries=20 against each KDC for each of some six GSSAPI mechanisms, at (IIRC) a=20 3-second timeout each. This was so bad that corrective action was taken,= =20 but there are still some delays if DNS is not functioning properly. -Ben Kaduk ---559023410-1512555890-1378955885=:16692--