Subject: Rekey issue

From: Mouse <[email-masked]>
Date: Wed, 8 Jun 2016 23:16:44 -0400 (EDT)

I've just tripped over an issue in my implementation and I was
wondering what people think the rightest behaviour is and/or what other
implementations do.

The problematic behaviour is: user connects to a host and accepts the
host key for this session only (ie, without recording it anywhere
permanent).  Then, on rekey, the client once again finds the host key
unlisted and wants user confirmation of its acceptability.

I can see at least three ways of dealing with this: (1) when rekeying,
always accept the host key regardless of what it is, (2) when rekeying,
require that the host key be what it was the first time around, always
accepting if it is and erroring if not, and (3) when rekeying, behave
as normal except that a second copy of the host key from the first time
around is, effectively, added as a trusted key for the host.

For the moment, I've done (1).  I'm wondering (a) what other
implementations do, (b) if I've missed an option above, and (c) what
people think should ideally be done.

It's also possible something is given in the spec for this and I just
missed it, though (since it's a user-interface issue) I'm inclined to
doubt it.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: [email-masked] (Niels Möller)
Date: Thu, 09 Jun 2016 13:15:34 +0200

> around is, effectively, added as a trusted key for the host.

I think I'm doing (3). That's what made most sense to me when I
implemented it, but maybe there are better options. When an unknown key
is received at the initial keyexchange, there are three possible
outcomes depending on the user interaction:

A. Disconnect.

B. Accepted only for this connection. Key is added to the in-memory list
   of trusted host keys.

C. Accepted. As above, but in addition, the key is appended to the host
   key list on disk.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.

---

From: Damien Miller <[email-masked]>
Date: Sun, 12 Jun 2016 17:03:03 +1000 (AEST)

On Wed, 8 Jun 2016, Mouse wrote:

> always accept the host key regardless of what it is, (2) when
> rekeying, require that the host key be what it was the first time
> around, always accepting if it is and erroring if not, and (3) when
> rekeying, behave as normal except that a second copy of the host key
> from the first time around is, effectively, added as a trusted key for
> the host.

OpenSSH does:

(4) silently accept the hostkey if it is identical to the one used to
authenticte the previous KEX, search the known hostkeys otherwise and
if not found there then do whatever is configured for hiterto-unknown
hostkeys. This could be automatically accepting, prompting the user or
unconditionally rejecting the key.

-d

---

From: Mouse <[email-masked]>
Date: Mon, 13 Jun 2016 20:35:34 -0400 (EDT)

>> I can see at least three ways of dealing with this: (1) [...], (2)
>> [...], and (3) when rekeying, behave as normal except that a second
>> copy of the host key from the first time around is, effectively,
>> added as a trusted key for the host.

> hostkeys.

I must be missing something.  To me, this sounds like (3).  What's the
difference?

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: [email-masked] (Niels Möller)
Date: Tue, 14 Jun 2016 14:48:00 +0200

> I must be missing something.  To me, this sounds like (3).  What's the

Not sure if the distinction was intended, and if so, if it matters, but
consider the case where the same (previously unknown) host key A occurs
in the first and third key exchange, but a distinct host key B is used
(and somehow accepted) in the second keyexchange.

In this scenario, (3) unconditionally accepts A as trusted when it
returns in the third key exchange, while (4) doesn't.

Regards,
/Niels

---

From: Mouse <[email-masked]>
Date: Tue, 14 Jun 2016 09:04:04 -0400 (EDT)

>> [two kex scenarios, I asked how they differed]
> [C]onsider the case where the same (previously unknown) host key A
> occurs in the first and third key exchange, but a distinct host key B
> is used (and somehow accepted) in the second keyexchange.

Ooh, well spotted.  Thank you.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign

---

From: "denis bider \(Bitvise\)" <[email-masked]>
Date: Tue, 14 Jun 2016 08:19:38 -0600

To me, this also sounds like (3). I also agree with this option.

From: Mouse 
Sent: Monday, June 13, 2016 18:35
To: [email-masked] 
Subject: Re: Rekey issue

/~\ The ASCII   Mouse
\ / Ribbon Campaign