openssh unix dev - Feb 2021 - SRV lookup support (Bugzilla 2217)

Hi,
>Secondly, if we do go ahead with it then we need to decide whether it
>should be on by default. I don't think that allowing a DNS
>owner/attacker
>to silently redirect traffic to a different port brings any new risk
>(after all, they could already send it to an entirely different host)
>but maybe I'm missing something...
I think if an attacker controls DNS, it's a lost game anyway. Current
implementation uses the same SSH hostkey mechanism after all, adding a SRV
record and moving SSH to another port still uses the hostkey already in the
database. For new hosts, know the fingerprint or trust DNS on first connection -
same as before. So, I think no added risk - but since it's another lookup,
which might slow things down, having an option might be a good idea anyway.
Thanks for that comment :)

RE demand, adding yet another feature: having a option, which is disabled by
default at first to check demand, might help enough with runtime cost.
Maintenance cost is another thing though. Hope there might be more comments from
the list.

Thanks for the style guidelines, will look into it.

Best regards
Mara Sophie Grosch

Am 18. Februar 2021 00:52:40 MEZ schrieb Damien Miller <djm at
mindrot.org>:
>On Mon, 15 Feb 2021, Mara Sophie Grosch wrote:
>
>> Hi there,
>> 
>> I'm new on this list and on the contribution side to this project,
so
>> please be gentle.
>> 
>> I want to tackle SRV lookup support in OpenSSH client, especially for
>> the use case of non-standard ports on the server - which is a part of
>> Bugzilla 2217 [1].
>> 
>> For that, I made a first implementation, hooking into `resolve_host`
>in
>> ssh.c, calling a new `resolve_srv` if no port is given on the command
>> line or config. Full patch is available as pull request on github[2].
>I
>> figured, discussing this here is probably better, since it's not
only
>a
>> change for non-OpenBSD OpenSSH.
>> 
>> I would love comments about my approach and about changes that would
>be
>> required for this to be merged - or discussion about how to better
>> approach this. Only invested an evening so far, so starting a new
>> wouldn't be a big problem if results are a lot better :)
>
>Hi,
>
>Thanks for working on OpenSSH!
>
>wrt the acceptability of this feature, I don't have a good sense of how
>much demand there is for it and how that balances against adding more
>complexity to the already pretty fiddly name resolution stuff that
>happens before connect.
>
> [Snipped]
>
>As a practical matter, your changes need some stylistic tweaks to
>match the formatting style we use (http://man.openbsd.org/style.9),
>but that's very much a secondary consideration.
>
>-d
-- 
Diese Nachricht wurde von meinem Android-Ger?t mit K-9 Mail gesendet.

On Thu, 18 Feb 2021, Mara Sophie Grosch wrote:
> >(after all, they could already send it to an entirely different host)
> >but maybe I'm missing something...
>
> I think if an attacker controls DNS, it's a lost game anyway. Current
It?s still a level of indirection that isn?t traditionally used, and
which makes me a bit nervous, especially considering name resolution
is not just DNS (think /etc/hosts for example).

I?d prefer for this ?feature? to be disabled by default and stay that
way.

bye,
//mirabilos
-- 
?MyISAM tables -will- get corrupted eventually. This is a fact of life. ?
?mysql is about as much database as ms access? ? ?MSSQL at least descends
from a database? ?it's a rebranded SyBase? ?MySQL however was born from a
flatfile and went downhill from there? ? ?at least jetDB doesn?t claim to
be a database?	(#nosec)    ??? Please let MySQL and MariaDB finally die!