openssh unix dev - Aug 2021 - OpenSSH support for FIDO RSA keys

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

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.

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 at 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 at 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