openssh unix dev - Jan 2014 - VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS

Hello list, I'm not sure whether this is bug worthy or just my own
insanity.  I'm using 6.4p1 packages from Debian jessie and
wheezy-backports.

I like VisualHostKey, although it may not add any protection (other than
not trusting ones own known_hosts file?), I've become accustomed to it
as it seems that extra neurons fire when I log into a host and get a
visual cue of what looks like a strawberry or jester hat and suddenly a
catalog of frequent commands relevant to the particular host surface in
mind ;-)

I have two configuration problems that make VisualHostKey less usable.

* RekeyLimit

I'm no crypto expert, pretty much cargo-culting here, but from bits and
pieces I've read, it seems like re-keying is crucial for a cipher like
AES-GCM.  Maybe it's just a gut feeling inspired by strongSwan IPsec
daemons which are constantly re-keying.

Every time the cipher is re-keyed, VisualHostKey clobbers the terminal,
usually with broken line feeds such that the ascii-art is unintelligible
and wraps off the right side of the terminal.  This is annoying,
especially with a screen(1) full of ssh sessions that may be idle and
re-keyed several times over a weekend, coming back and having to work
through clearing the screens of each session (^L suffices for a shell or
emacs, but sometimes the session is in a curses application, or lost
information while tailing a log, etc.).  This gets uglier when making
use of the fantastic ControlPersist options - seemingly logged out ssh
session still blast the initial terminal with re-keying fingerprints.

* VerifyHostKeyDNS=yes

It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
neither displayed on initial connection, or on re-keying (good).

So I have a funny setup:

  For hosts which have SSHFP records, I have set VerifyHostKeyDNS=yes
  and ineffectively set VisualHostKey=yes (never prints), and can also
  set a timed RekeyLimit rate.

  For hosts which don't have SSHFP, I could leave RekeyLimit at the
  default (1G none) and rarely see the re-key fingerprints, however in
  an all-or-nothing sort of decision, simply set VisualHostKey=no and be
  done with it.

Am I missing something?  Is there a way to comfortably get VisualHostKey
back?  Perhaps a trivial/wishlist bug with re-keying should be filed?

Perhaps this is already solved by bug 2154, "Avoid key lookup overhead
when re-keying":

  https://bugzilla.mindrot.org/show_bug.cgi?id=2154

P.S. I think it's wonderful you folks are working on curve25519,
ed25519, and chacha20+poly1305.  I've moved a bunch of systems to ECDHE
last year, great speedup, especially from crap Atom clients, but feel
that I've shot myself in the foot after Schneier's denouncement of the
NIST curves.

-- 
Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140102/0c48aa5d/attachment.bin>

On Thu, 2 Jan 2014, Gerald Turner wrote:
> Hello list, I'm not sure whether this is bug worthy or just my own
> insanity.  I'm using 6.4p1 packages from Debian jessie and
> wheezy-backports.
> 
> I like VisualHostKey, although it may not add any protection (other than
> not trusting ones own known_hosts file?), I've become accustomed to it
> as it seems that extra neurons fire when I log into a host and get a
> visual cue of what looks like a strawberry or jester hat and suddenly a
> catalog of frequent commands relevant to the particular host surface in
> mind ;-)
> 
> I have two configuration problems that make VisualHostKey less usable.
> 
> * RekeyLimit
> 
> I'm no crypto expert, pretty much cargo-culting here, but from bits and
> pieces I've read, it seems like re-keying is crucial for a cipher like
> AES-GCM.  Maybe it's just a gut feeling inspired by strongSwan IPsec
> daemons which are constantly re-keying.
> 
> Every time the cipher is re-keyed, VisualHostKey clobbers the terminal,
> usually with broken line feeds such that the ascii-art is unintelligible
> and wraps off the right side of the terminal.  This is annoying,
> especially with a screen(1) full of ssh sessions that may be idle and
> re-keyed several times over a weekend, coming back and having to work
> through clearing the screens of each session (^L suffices for a shell or
> emacs, but sometimes the session is in a curses application, or lost
> information while tailing a log, etc.).  This gets uglier when making
> use of the fantastic ControlPersist options - seemingly logged out ssh
> session still blast the initial terminal with re-keying fingerprints.
Could you please file a bug for this on https://bugzilla.mindrot.org/ ?
We should suppress the message on rekeying.
> * VerifyHostKeyDNS=yes
> 
> It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
> neither displayed on initial connection, or on re-keying (good).
If you really want to see it, maybe we could make a
VisualHostKey=always option?
> So I have a funny setup:
> 
>   For hosts which have SSHFP records, I have set VerifyHostKeyDNS=yes
>   and ineffectively set VisualHostKey=yes (never prints), and can also
>   set a timed RekeyLimit rate.
> 
>   For hosts which don't have SSHFP, I could leave RekeyLimit at the
>   default (1G none) and rarely see the re-key fingerprints, however in
>   an all-or-nothing sort of decision, simply set VisualHostKey=no and be
>   done with it.
> 
> Am I missing something?  Is there a way to comfortably get VisualHostKey
> back?  Perhaps a trivial/wishlist bug with re-keying should be filed?
> 
> Perhaps this is already solved by bug 2154, "Avoid key lookup overhead
> when re-keying":
> 
>   https://bugzilla.mindrot.org/show_bug.cgi?id=2154
Yes, it probably is.
> P.S. I think it's wonderful you folks are working on curve25519,
> ed25519, and chacha20+poly1305.  I've moved a bunch of systems to ECDHE
> last year, great speedup, especially from crap Atom clients, but feel
> that I've shot myself in the foot after Schneier's denouncement of
the
> NIST curves.
IMO the concerns about the NIST EC curves are a bit overblown. If the NSA
had some way of breaking EC directly, then they wouldn't need to resort
to things like Dual_EC_DRBG.

-d