Mailing List Archive

On Thu, 2021-08-19 at 11:25 +0200, Jan Schermer wrote:
> Hello,
> I would like to deploy FIDO for SSH. I wanted to leverage Windows
> Hello on Windows clients as FIDO backend (so that I don’t have to buy
> hw tokens for everyone and for convenience), but evidently my TPM
> flavor doesn’t support ECDSA, only RSA.

This likely means you have TPM 1.2

> Would it be possible to extend OpenSSH support to include “rsa-sk”
> keys?
>
> Not sure what the process is, but could development of it be
> sponsored?

The FIDO standard requires ECDSA keys (mainly, I suspect, because some
of the space constraints in the protocol are too small for RSA) so I
don't believe, even if you hacked the standard to support RSA keys,
that it would work in practice.

I'd strongly suggest you find a TPM 2.0 system, or simply use a FIDO
token via a non-TPM emulator to get ECDSA keys.

James


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 25 Aug 2021, James Bottomley wrote:

> > Would it be possible to extend OpenSSH support to include “rsa-sk”
> > keys?
> >
> > Not sure what the process is, but could development of it be
> > sponsored?
>
> The FIDO standard requires ECDSA keys (mainly, I suspect, because some
> of the space constraints in the protocol are too small for RSA) so I
> don't believe, even if you hacked the standard to support RSA keys,
> that it would work in practice.

AFAIK the FIDO2 standards include RSA keys, though I'm not aware of any
physical FIDO tokens that support them (caveat: I haven't looked much).

Adding another key type to OpenSSH is expensive - it needs to be plumbed
through a lot of code, tests need to be written, documentation updated
and fuzzing seed corpora need to be created. Maintenance once it has
been added is less onerous, but still a factor - each supported key type
basically increases the multiple (currently 7) of code paths that need
care, test coverage and fuzzing.

OTOH it's really hard to *remove* a key type, because there's always
someone, somewhere with some use case that wants it. I'm expecting a big
fight when I eventually push to remove ssh-dss, an algorithm that is
demonstrably insecure, despite it being disabled by default for a long
time. So anything we add, we're almost certainly on the hook to support
for a decade+

Because of this, I'm quite reticent to add more key types without a
really compelling reason.

In the case of RSA/FIDO, it's really to support a single vendor
(admittedly an important one), but using an algorithm (RSA) which almost
everyone is moving away from in favour of elliptic-curve crypto, and
that seems was chosen to support a legacy hardware standard (TPM 1.x)
that is already superseded.

It feels like adding FIDO/RSA is like running towards where the ball was
a year ago rather than where it will be in the near future.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Damien Miller wrote:
> I'm expecting a big fight when I eventually push to remove ssh-dss,

FWIW I think that's long overdue, and understand your worry.


> In the case of RSA/FIDO, it's really to support a single vendor
> (admittedly an important one), but using an algorithm (RSA) which
> almost everyone is moving away from in favour of elliptic-curve crypto,

Many are indeed moving, but popularity in itself doesn't really mean much.
I for one like RSA in spite of the many caveats now known, because the math
is simple (to me). But I by no means hate or reject ECC, it's just different.
(Yes, ECC code can be simpler than RSA code.)


> and that seems was chosen to support a legacy hardware standard (TPM 1.x)
> that is already superseded.

I think the reason to add RSA/FIDO should be less to support TPM 1.x
and more to create opportunity and/or a use-case for future RSA tokens.

I understand the code coverage concern, but since RSA is already
quite heavily used in OpenSSH, would the overhead actually be large?

The FIDO code would of course grow, were you refering to that all along?


Thanks and kind regards

//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 28/8/21 2:57 am, Peter Stuge wrote:
> Damien Miller wrote:
>> I'm expecting a big fight when I eventually push to remove ssh-dss,
> FWIW I think that's long overdue, and understand your worry.

I, too, understand your worry, but I also understand why there will be a
lot of pushback against removing it.

A lot of equipment, perfectly good equipment, expensive equipment, but
old equipment requires it.  Most of it is behind a security appliance so
there's no real risk is negligible if indeed it's not actually zero.

Removing DSS removes management access to the equipment and the only
reason is a pedantic complaint that DSS is trivially broken.

Please don't break equipment over well-meaning pedantry.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 30 Aug 2021, David Newall wrote:

> A lot of equipment, perfectly good equipment, expensive equipment, but
> old equipment requires it.  Most of it is behind a security appliance so
> there's no real risk is negligible if indeed it's not actually zero.
>
> Removing DSS removes management access to the equipment and the only
> reason is a pedantic complaint that DSS is trivially broken.
>
> Please don't break equipment over well-meaning pedantry.

I bet this (once) expensive equipment still supports telnet, so
nothing is being broken.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 30 Aug 2021, Damien Miller wrote:

> I bet this (once) expensive equipment still supports telnet, so
> nothing is being broken.

Not necessarily. Besides, telnet clients are also in short supply;
didn’t OpenBSD remove it from base? It also doesn’t have all those
nice features SSH has, file transfer, channels, etc. of which only
a subset may actually apply for the appliances but still…

bye,
//mirabilos
--
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

****************************************************
/?\ The UTF-8 Ribbon
? ? Campaign against Mit dem tarent-Newsletter nichts mehr verpassen:
? HTML eMail! Also, https://www.tarent.de/newsletter
? ? header encryption!
****************************************************
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> > A lot of equipment, perfectly good equipment, expensive equipment, but
> > old equipment requires it. Most of it is behind a security appliance so
> > there's no real risk is negligible if indeed it's not actually zero.
> >
> > Removing DSS removes management access to the equipment and the only
> > reason is a pedantic complaint that DSS is trivially broken.
> >
> > Please don't break equipment over well-meaning pedantry.
>
> I bet this (once) expensive equipment still supports telnet, so
> nothing is being broken.

even if it doesn't, the idea that someone would assume support of this
equipment is the responsibility of the openssh maintainers, rather
than the _vendor_, blows my mind.

save a statically linked copy of openssh that supports your old
crypto, problem solved.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hello,
thank you all for comments.

I am testing on a Dell E5410 laptop equipped with TPM 2.0.
I am using this piece of software to use Windows Hello in SSH:
https://github.com/tavrez/openssh-sk-winhello <https://github.com/tavrez/openssh-sk-winhello>

When trying to generate key like this:
SSH_SK_PROVIDER=winhello.dll ssh-keygen -t ecdsa-sk

^ I am prompted to insert a Security Key (and if I do everything works)

I opened an issue in that project here:
https://github.com/tavrez/openssh-sk-winhello/issues/9 <https://github.com/tavrez/openssh-sk-winhello/issues/9>

Which led me to believe it was a winhello.dll limitation, but it doesn’t seem to be.

When testing “real” FIDO (webauthn) on webauthn.io <http://webauthn.io/>, it seems to be using RSA keys only as well.

I also tried webauthn.me <http://webauthn.me/> and there I had to use the debugging mode and set the key to RSASSA instead of ECDSA to make it work with the TPM.

So maybe Windows Hello really doesn’t support anything but RSA? I don’t have any other (TPM 2.0) Windows device on hand (and even if I did, this it the hardware we use), so I’m not able to really test it.

I think support for RSA would be great, even if only to get around possible Windows Hello limitations. For me, the main reasons for using Windows Hello are
1) Price. It’s hard to convince your corporation to buy thousands of FIDO keys _and_ to create supporting processes for lost keys and stuff, but Windows Hello is already present on all corporate devices and just needs to be enabled. The hardware itself and user accounts tied to the keys are already secured (and disabled in case of theft etc.).
2) FIDO itself is great because of attestation, otherwise we are stuck using ISO format smartcards with X509 certificates (and using those to infer SSH keys). Not nice or usable

So getting FIDO adopted (in any form) is a way to get your foot into door of corporate vendor-locked PKI. Security Key market is not yet infested with hot water peddlers and even vendors seem to understand (or are forced to fake) why it should be standard and open. Being able to use Windows Hello just makes it so much easier to adopt and it’s hard for vendors to dispute integral technology behind today’s Window security...

I am not going to argue for/against RSA vs ECDSA, but AFAIK RSA is not a “bad” algorithm in any way (implementations might have many flaws, but that’s just because RSA is ubiquitous and old), and even if it gets broken or weak one day, disabling it in OpenSSH will be the least of IT world problems :-)

Jan


> On 27. 8. 2021, at 19:27, Peter Stuge <peter@stuge.se> wrote:
>
> Damien Miller wrote:
>> I'm expecting a big fight when I eventually push to remove ssh-dss,
>
> FWIW I think that's long overdue, and understand your worry.
>
>
>> In the case of RSA/FIDO, it's really to support a single vendor
>> (admittedly an important one), but using an algorithm (RSA) which
>> almost everyone is moving away from in favour of elliptic-curve crypto,
>
> Many are indeed moving, but popularity in itself doesn't really mean much.
> I for one like RSA in spite of the many caveats now known, because the math
> is simple (to me). But I by no means hate or reject ECC, it's just different.
> (Yes, ECC code can be simpler than RSA code.)
>
>
>> and that seems was chosen to support a legacy hardware standard (TPM 1.x)
>> that is already superseded.
>
> I think the reason to add RSA/FIDO should be less to support TPM 1.x
> and more to create opportunity and/or a use-case for future RSA tokens.
>
> I understand the code coverage concern, but since RSA is already
> quite heavily used in OpenSSH, would the overhead actually be large?
>
> The FIDO code would of course grow, were you refering to that all along?
>
>
> Thanks and kind regards
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://www.google.com/url?q=https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev&source=gmail-imap&ust=1630690230000000&usg=AOvVaw0g2hTB10t4n7Km8FrD--nL

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Am Mo., 30. Aug. 2021 um 05:25 Uhr schrieb Thorsten Glaser <t.glaser@tarent.de>:
> Not necessarily. Besides, telnet clients are also in short supply;
> didn’t OpenBSD remove it from base?

Only the server.

Best
Martin
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 30/8/21 1:53 pm, Peter Moody wrote:
>> I bet this (once) expensive equipment still supports telnet, so
>> nothing is being broken.
> even if it doesn't, the idea that someone would assume support of this
> equipment is the responsibility of the openssh maintainers, rather
> than the_vendor_, blows my mind.

That's an absurd mis-characterisation of what I said.  Perhaps you sent
your message in injudicious haste.

Damien said that he plans to remove support for DSS keys at some future
time.  That will take effort and I bet leaving them in the code will
take none.

I'm saying, don't put in that effort because it will needlessly break
equipment.  Deprecate it to all hell, but don't remove it. In no
possible way can that be conflated with me saying that openssh
maintainers have to support anybody's equipment.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 30.08.21 05:01, Damien Miller wrote:
> On Mon, 30 Aug 2021, David Newall wrote:
>> Removing DSS removes management access to the equipment and the only
>> reason is a pedantic complaint that DSS is trivially broken.
>>
>> Please don't break equipment over well-meaning pedantry.
>
> I bet this (once) expensive equipment still supports telnet, so
> nothing is being broken.

As long as the definition of "getting broken" covers "things suddenly
stop working as they were", it *still* breaks setups where plain
TELNET+FTP has been disabled or firewalled in favor of "more secure" SSH.

Which doesn't mean that DSS, and thus the firmware's implementation of
SSH, should not be considered the thing to have broken *first*, but.

On 30.08.21 06:23, Peter Moody wrote:
> even if it doesn't, the idea that someone would assume support of this
> equipment is the responsibility of the openssh maintainers, rather
> than the _vendor_, blows my mind.

FWIW, I'm *nowhere* near labeling any specific problem of *mine* a
"responsibility* of the OpenSSH developers.

Pray tell, though, at what level does "a bunch of somebodies" turn into
"a compatibility issue" or "a valid use case" or somesuch?

$ cat .ssh/config .ssh/config.d/* | grep -c '^Host'
709
$ cat .ssh/config .ssh/config.d/* | grep dss
HostKeyAlgorithms ssh-dss
HostKeyAlgorithms ssh-dss
HostKeyAlgorithms +ssh-dss
HostKeyAlgorithms +ssh-dss
HostKeyAlgorithms +ssh-dss
HostKeyAlgorithms +ssh-dss

(Yes, I already default-disabled DSS on my workplace machine. And no,
not all of those six targets are someplace I can easily set up a VPN to,
or a VM with a current OpenSSH server in.)

> save a statically linked copy of openssh that supports your old
> crypto, problem solved.

*sigh* Right *now*, I *could* do that ... our auditors have had "version
control of *Linux*-based workplace computers, too" on their wishlist for
quite a while, though.

Regards,
--
Jochen Bern
Systemingenieur

Binect GmbH

On 2021/08/30 11:43, David Newall wrote:
> On 28/8/21 2:57 am, Peter Stuge wrote:
> > Damien Miller wrote:
> > > I'm expecting a big fight when I eventually push to remove ssh-dss,
> > FWIW I think that's long overdue, and understand your worry.
>
> I, too, understand your worry, but I also understand why there will be a lot
> of pushback against removing it.
>
> A lot of equipment, perfectly good equipment, expensive equipment, but old
> equipment requires it.? Most of it is behind a security appliance so there's
> no real risk is negligible if indeed it's not actually zero.
>
> Removing DSS removes management access to the equipment and the only reason
> is a pedantic complaint that DSS is trivially broken.
>
> Please don't break equipment over well-meaning pedantry.

Oh not this one again. OpenSSH already removed support for things used
by some devices. It is annoying but the world didn't end - if you need
to use some separate legacyssh binary (sometimes spelt 'p l i n k') to
connect it acts as a good reminder that you're not really using a secure
protocol for that connection.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Stuart Henderson <stu@spacehopper.org> writes:

> On 2021/08/30 11:43, David Newall wrote:
>> On 28/8/21 2:57 am, Peter Stuge wrote:
>> > Damien Miller wrote:
>> > > I'm expecting a big fight when I eventually push to remove ssh-dss,
>> > FWIW I think that's long overdue, and understand your worry.
>>
>> I, too, understand your worry, but I also understand why there will be a lot
>> of pushback against removing it.
>>
>> A lot of equipment, perfectly good equipment, expensive equipment, but old
>> equipment requires it.? Most of it is behind a security appliance so there's
>> no real risk is negligible if indeed it's not actually zero.
>>
>> Removing DSS removes management access to the equipment and the only reason
>> is a pedantic complaint that DSS is trivially broken.
>>
>> Please don't break equipment over well-meaning pedantry.
>
> Oh not this one again. OpenSSH already removed support for things used
> by some devices. It is annoying but the world didn't end - if you need
> to use some separate legacyssh binary (sometimes spelt 'p l i n k') to
> connect it acts as a good reminder that you're not really using a secure
> protocol for that connection.

I agree -- I believe it is important that users of OpenSSH end up with
secure channels, since that is the expectation that OpenSSH gives.

Support for insecure algorithms and features can be moved to a
side-project called (say) 'InscuriSSH' and a tool 'ish', if there is
enough interest to maintain it, similar in spirit to the OpenSSH
Portability version.

Count me as +1 on removing ssh-dss now.

/Simon

> That will take effort and I bet leaving them in the code will take none.

neither you nor I are maintainers of openssh, but with unit tests and
configure options, this strikes me as a weird assumption to make.

look, this comes up every time openssh removes support for some
horribly broken crypto. "you're making my devices inaccessible, how
could you!?" and the answer is always the same,

1. you're free to maintain a copy of the ssh client that supports
your old devices.
2. you should be complaining to your hardware vendor, to whom you
pay/paid actual money.

as a thought experiment, imagine asking the chrome devs to keep
supporting ssl v3 because some commercial appliance you run hasn't
been updated in a decade.

/rant
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

> as a thought experiment, imagine asking the chrome devs to keep
supporting ssl v3 because some commercial appliance you run hasn't
been updated in a decade.

From what I recall that was an issue. I can tell you that there will always
be people who have antiquated legacy equipment they cannot update that will
support antiquated legacy protocols.

One insight that I have however is that the people who have those pieces of
legacy equipment are more likely to be large companies than private
individuals. I will also note that there are great benefits to removing
legacy code - they were often written during more un-enlightened times and
may have their own cruft that makes the overall system harder to maintain.
Less technical debt is also likely to lead to better code when you can
focus on the amount remaining. After all, is there nothing more sublime
then deleting code to improve your deliverable?

I'd humbly suggest that if people really want to have an official "legacy
OpenSSH" they should pay Damien to maintain it. Going back to my above
point, most end users who need ssh-dss are big companies with locked in
hardware that cannot be updated. They should be able to spare some dollars
to support connecting to their equipment. I'm sure that whatever is worked
out will be less than hiring consultants to come up with a solution to
maintain a legacy binary.

Cheers,

Ethan

On Mon, Aug 30, 2021 at 8:51 AM Peter Moody <mindrot@hda3.com> wrote:

> > That will take effort and I bet leaving them in the code will take none.
>
> neither you nor I are maintainers of openssh, but with unit tests and
> configure options, this strikes me as a weird assumption to make.
>
> look, this comes up every time openssh removes support for some
> horribly broken crypto. "you're making my devices inaccessible, how
> could you!?" and the answer is always the same,
>
> 1. you're free to maintain a copy of the ssh client that supports
> your old devices.
> 2. you should be complaining to your hardware vendor, to whom you
> pay/paid actual money.
>
> as a thought experiment, imagine asking the chrome devs to keep
> supporting ssl v3 because some commercial appliance you run hasn't
> been updated in a decade.
>
> /rant
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev