Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread James Bottomley 
On Tue, 2017-01-03 at 16:40 -0700, Jason Gunthorpe wrote:
> On Tue, Jan 03, 2017 at 03:22:56PM -0800, James Bottomley wrote:
> > > I think it is very important to natively support the sign-only 
> > > key usage restriction. TPM1.2 goes so far as to declare keys that 
> > > can be used for arbitary decrypt as 'legacy do not use'.
> > > 
> > > IMHO the best way to do this is to look at the sign operation 
> > > openssl is trying to do and see if it can be sent down the sign 
> > > path to the TPM. Only if that fails should the decrypt path be
> > > used.
> > 
> > The problem is the MD5-SHA1 signature of SSL and TLS < v1.2.   This
> > cannot be performed by the TPM because it's not listed as a 
> > supported signature, so the choice is either to deprecate these 
> > protocols (not really viable since they're in wide use in old 
> > websites) or use decrypt to do the signatures.  Once we get to the 
> > point of having to use decrypt, there's no reason to preserve the 
> > signing distinction since we never know when a key will be used to
> > decrypt or sign.
> 
> I'm not disputing your analysis, just remarking that it seem very
> undesirable to ban *all* sign-only keys just to support a single
> legacy SSL configuration.

It's not just a single situation.  MD5-SHA1 is where it will fall apart
on backwards compatibility but my current TPM doesn't understand
anything other than sha1 or sha256, so it wouldn't allow more state of
the art algorithms like sha224, sha384 or sha512 either.

> This is why I suggest looking at the sign being requested and using
> the sign path if it is *possible*, otherwise requiring a key with the
> broader key usage.

It's a trade off: the user configuration nightmare: how does an
ordinary user know what type of TPM key they need ... they'll need to
know what their TPM is capable of and what signatures they're likely to
need.  VS the benefits of having single use keys.

I'm just not sure I see enough benefits to trying to preserve the
decrypt vs sign distinction, whereas I do see the floods of complaints
from users who got it wrong or think it should work as advertised.

> Not everything is SSL - openssh uses these routines too and it should
> be able to use the sign only key type without a limitation?

Agreed that openssh only has forward compatibility problems, but it
still has them thanks to the newer algorithm problem.

Actually, the next problem would be gnome-keyring.  It does openssl
signatures and fishing the algorithm type out by the time 

James

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread Richard Levitte 
In message <1483487075.2464.59.ca...@hansenpartnership.com> on Tue, 03 Jan 2017 
15:44:35 -0800, James Bottomley  said:

James.Bottomley> On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote:
James.Bottomley> > ⁣There seems to be some confusion here. 
James.Bottomley> > 
James.Bottomley> > James, I understand the tpm engine as an external project, 
not part
James.Bottomley> > of the OpenSSL source proper and not intended to be. 
James.Bottomley> > 
James.Bottomley> > However, openssl-dev@openssl.org is a list focused on the 
development
James.Bottomley> > of OpenSSL proper. That makes it a bit odd to discuss the 
tpm engine
James.Bottomley> > here. Largely off topic. 
James.Bottomley> 
James.Bottomley> Fair enough.  You were cc'd since it's a modification of code 
used by
James.Bottomley> openSSL, in case there was interest.

Strictly speaking, that belongs in openssl-us...@openssl.org.

The reason I point this out is that for code that isn't meant to be
part of OpenSSL proper, the whole discussion about CLAs, licenses and
whatnot is a red herring that belongs neither here not there.  As long
as you do stuff as a separate project, YOU (collective you) decide
what license to use, let alone your contribution policy.

Of course, I do recall that there was an attempt of patches to be
applied to OpenSSL proper.  That alone is subject to our license and
our policies, if that's still interesting (I don't know if it is).  If
it is, that should be contributed as a separate patch, preferably as a
github PR (sourceforge is entirely uninteresting to us).

Me, I haven't really minded the discussion here, as long as it didn't
become confusing.  After all, it did spark some discussion around my
STORE project ;-)

Did I leave something out or is the situation clear?

Cheers,
Richard

-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread James Bottomley 
On Wed, 2017-01-04 at 00:04 +, Matt Caswell wrote:
> 
> On 03/01/17 12:44, Salz, Rich wrote:
> > > > I'm still waiting on a reply ... I assume holidays are
> > > > contributing to the delay.
> > > > However, openssl_tpm_engine is a DCO project, so that concern
> > > > is
> > > > irrelevant here.
> > > 
> > > Sorry, I'll push to get the bylaws made public, is that what you
> > > need?
> > 
> > The OSF bylaws are now linked to from 
> > https://www.openssl.org/policies/
> 
> I can't actually see this link...am I just missing it, or did you not 
> push?


https://www.openssl.org/policies/osf-bylaws.pdf

Thanks for doing this!

James

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread Matt Caswell 


On 03/01/17 12:44, Salz, Rich wrote:
>>> I'm still waiting on a reply ... I assume holidays are contributing to the 
>>> delay.
>>> However, openssl_tpm_engine is a DCO project, so that concern is
>>> irrelevant here.
>>
>> Sorry, I'll push to get the bylaws made public, is that what you need?
> 
> The OSF bylaws are now linked to from https://www.openssl.org/policies/

I can't actually see this link...am I just missing it, or did you not push?

Matt

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread James Bottomley 
On Tue, 2017-01-03 at 12:19 +0100, Richard Levitte wrote:
> ⁣There seems to be some confusion here. 
> 
> James, I understand the tpm engine as an external project, not part
> of the OpenSSL source proper and not intended to be. 
> 
> However, openssl-dev@openssl.org is a list focused on the development
> of OpenSSL proper. That makes it a bit odd to discuss the tpm engine
> here. Largely off topic. 

Fair enough.  You were cc'd since it's a modification of code used by
openSSL, in case there was interest.

James


> Cheers 
> Richard 
> 
> Skickat från BlueMail 
> 
> Den 2 jan. 2017 19:22, kI 19:22, "Salz, Rich" 
> skrev:
> > > Really, how?  By pull request, you mean one against the openssl
> > github
> > > account so people subscribing to that account see it, I presume? 
> > >  For
> > that to
> > > happen, the tree the patch is against must actually exist within
> > > the
> > account,
> > > which this one doesn't.
> > 
> > You clone the openssl git repo, create your own branch off master,
> > apply the diffs you are mailing to the list, and commit/push and
> > then
> > make a PR.  Yes it's a bit of work for you.  But it then becomes
> > near-zero work for anyone on openssl to look at it.
> > 
> > > This patch is mostly FYI, so yes, I do given that multiple
> > > mailing
> > lists have
> > > some interest.
> > 
> > It's all about trade-offs.  Multiple people have said multiple
> > times
> > that PR's are the best way to work with OpenSSL.  If those other
> > groups, individually or collectively, are higher on your priority
> > list,
> > that's fine.  But do understand what's going on.
> > 
> > > I'm still waiting on a reply ... I assume holidays are
> > > contributing
> > to the delay.
> > > However, openssl_tpm_engine is a DCO project, so that concern is
> > irrelevant
> > > here.
> > 
> > Sorry, I'll push to get the bylaws made public, is that what you
> > need?
> > 
> > And no, it's not irrelevant.  If this is ever going to appear in
> > OpenSSL, a CLA must be signed.
> > 
> > -- 
> > openssl-dev mailing list
> > To unsubscribe: 
> > https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread James Bottomley 
On Mon, 2017-01-02 at 18:22 +, Salz, Rich wrote:
> > I'm still waiting on a reply ... I assume holidays are contributing 
> > to the delay. However, openssl_tpm_engine is a DCO project, so that 
> > concern is irrelevant here.
> 
> Sorry, I'll push to get the bylaws made public, is that what you
> need?

There were two requests: the bylaws and whether modified grant would be
acceptable.  If, instead of an unrestricted grant in the CLA it were
restricted to relicensing to an OSI approved licence, the need to do
due diligence on the foundation goes away.

> And no, it's not irrelevant.  If this is ever going to appear in
> OpenSSL, a CLA must be signed.

It's not actually my code: I'm just updating it, so I'm unable to say
what the long term plan actually is.  I would think, though, that
hardware engines, since they're highly OS support dependent, would be
difficult to keep within openssl itself given that you want to compile
on multiple platforms.

James

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread Piche, Simon 


-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of James 
Bottomley
Sent: Tuesday, January 03, 2017 6:23 PM
To: Jason Gunthorpe 
Cc: trousers-t...@lists.sourceforge.net; tpmdd-de...@lists.sourceforge.net; 
ibmtpm20tss-us...@lists.sourceforge.net; openssl-dev@openssl.org
Subject: Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 
version of create_tpm2_key and libtpm2.so engine

On Tue, 2017-01-03 at 16:11 -0700, Jason Gunthorpe wrote:
> On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > This patch adds RSA signing for TPM2 keys.  There's a limitation to 
> > the way TPM2 does signing: it must recognise the OID for the 
> > signature.  That fails for the MD5-SHA1 signatures of the TLS/SSL 
> > certificate verification protocol, so I'm using RSA_Decrypt for both 
> > signing (encryption) and decryption ... meaning that this only works 
> > with TPM decryption keys.  It is possible to use the prior code, 
> > which preserved the distinction of signing and decryption keys, but 
> > only at the expense of not being able to support SSL or TLS lower 
> > than 1.2
> 
> [Note, I haven't looked closely at TPM2, but TPM1.2 has a concept of  
> key usage, and I assume that is carried over in the below comments]

The TPM1.2 all uses the correct signing functions, the problem is only with 2.0.

> I think it is very important to natively support the sign-only key 
> usage restriction. TPM1.2 goes so far as to declare keys that can be 
> used for arbitary decrypt as 'legacy do not use'.
> 
> IMHO the best way to do this is to look at the sign operation openssl 
> is trying to do and see if it can be sent down the sign path to the 
> TPM. Only if that fails should the decrypt path be used.

The problem is the MD5-SHA1 signature of SSL and TLS < v1.2.   This
cannot be performed by the TPM because it's not listed as a supported 
signature, so the choice is either to deprecate these protocols (not really 
viable since they're in wide use in old websites) or use decrypt to do the 
signatures.  Once we get to the point of having to use decrypt, there's no 
reason to preserve the signing distinction since we never know when a key will 
be used to decrypt or sign.

Note that google took an alternative approach and modified their TSS to work 
with a MD5-SHA1 signature:

https://chromium-review.googlesource.com/#/c/420811/

But this requires a modification to the TPM as well, which we can't do.

> For TPM1.2 you could create a sign-only key with the 
> TPM_SS_RSASSAPKCS1v15_DER mode and feed it arbitary NIDs - the TPM did 
> not check the data to sign, AFAIK.
> 
> Ideally the user should be able to setup a sign-only key and the 
> correct SSL negotiation parameters and have a working system, eg a 
> sign-only key used with TLS 1.3 and ephemeral keyx should work.
> 
> > +   /* this is slightly paradoxical that we're doing a Decrypt
> > +* operation: the only material difference between decrypt
> > and
> > +* encrypt is where the padding is applied or checked, so
> > if
> > +* you apply your own padding up to the RSA block size and
> > use
> > +* TPM_ALG_NULL, which means no padding check, a decrypt
> > +* operation effectively becomes an encrypt */
> 
> IIRC this duality is exactly why key usage exists, and why good crypto 
> practice has been to forbid decrypt/encrypt on the same key.

Given the signature restrictions, TPM 2.0 just can't be made to work with the 
older SSL/TLS protocols, so I'm opting to keep compatibility and not benefit 
from the distinction between signing and decryption keys.

James

> Jason
> 
> -
> -
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot 
> ___
> TrouSerS-tech mailing list
> trousers-t...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/trousers-tech
> 

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [TrouSerS-tech] [tpmdd-devel] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread James Bottomley 
On Tue, 2017-01-03 at 16:11 -0700, Jason Gunthorpe wrote:
> On Sat, Dec 31, 2016 at 02:52:43PM -0800, James Bottomley wrote:
> > This patch adds RSA signing for TPM2 keys.  There's a limitation to 
> > the way TPM2 does signing: it must recognise the OID for the 
> > signature.  That fails for the MD5-SHA1 signatures of the TLS/SSL 
> > certificate verification protocol, so I'm using RSA_Decrypt for 
> > both signing (encryption) and decryption ... meaning that this only 
> > works with TPM decryption keys.  It is possible to use the prior 
> > code, which preserved the distinction of signing and decryption 
> > keys, but only at the expense of not being able to support SSL or
> > TLS lower than 1.2
> 
> [Note, I haven't looked closely at TPM2, but TPM1.2 has a concept of
>  key usage, and I assume that is carried over in the below comments]

The TPM1.2 all uses the correct signing functions, the problem is only
with 2.0.

> I think it is very important to natively support the sign-only key
> usage restriction. TPM1.2 goes so far as to declare keys that can be
> used for arbitary decrypt as 'legacy do not use'.
> 
> IMHO the best way to do this is to look at the sign operation openssl
> is trying to do and see if it can be sent down the sign path to the
> TPM. Only if that fails should the decrypt path be used.

The problem is the MD5-SHA1 signature of SSL and TLS < v1.2.   This
cannot be performed by the TPM because it's not listed as a supported
signature, so the choice is either to deprecate these protocols (not
really viable since they're in wide use in old websites) or use decrypt
to do the signatures.  Once we get to the point of having to use
decrypt, there's no reason to preserve the signing distinction since we
never know when a key will be used to decrypt or sign.

Note that google took an alternative approach and modified their TSS to
work with a MD5-SHA1 signature:

https://chromium-review.googlesource.com/#/c/420811/

But this requires a modification to the TPM as well, which we can't do.

> For TPM1.2 you could create a sign-only key with the
> TPM_SS_RSASSAPKCS1v15_DER mode and feed it arbitary NIDs - the TPM 
> did not check the data to sign, AFAIK.
> 
> Ideally the user should be able to setup a sign-only key and the
> correct SSL negotiation parameters and have a working system, eg a
> sign-only key used with TLS 1.3 and ephemeral keyx should work.
> 
> > +   /* this is slightly paradoxical that we're doing a Decrypt
> > +* operation: the only material difference between decrypt
> > and
> > +* encrypt is where the padding is applied or checked, so
> > if
> > +* you apply your own padding up to the RSA block size and
> > use
> > +* TPM_ALG_NULL, which means no padding check, a decrypt
> > +* operation effectively becomes an encrypt */
> 
> IIRC this duality is exactly why key usage exists, and why good 
> crypto practice has been to forbid decrypt/encrypt on the same key.

Given the signature restrictions, TPM 2.0 just can't be made to work
with the older SSL/TLS protocols, so I'm opting to keep compatibility
and not benefit from the distinction between signing and decryption
keys.

James

> Jason
> 
> -
> -
> Check out the vibrant tech community on one of the world's most 
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> ___
> TrouSerS-tech mailing list
> trousers-t...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/trousers-tech
> 

-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread Salz, Rich 
> > I'm still waiting on a reply ... I assume holidays are contributing to the 
> > delay.
> > However, openssl_tpm_engine is a DCO project, so that concern is
> > irrelevant here.
> 
> Sorry, I'll push to get the bylaws made public, is that what you need?

The OSF bylaws are now linked to from https://www.openssl.org/policies/ or 
available directly at https://www.openssl.org/policies/osf-bylaws.pdf 
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] [PATCH 1/1] add TPM2 version of create_tpm2_key and libtpm2.so engine

2017-01-03 Thread Richard Levitte 
⁣There seems to be some confusion here. 

James, I understand the tpm engine as an external project, not part of the 
OpenSSL source proper and not intended to be. 

However, openssl-dev@openssl.org is a list focused on the development of 
OpenSSL proper. That makes it a bit odd to discuss the tpm engine here. Largely 
off topic. 

Cheers 
Richard 

Skickat från BlueMail ​

Den 2 jan. 2017 19:22, kI 19:22, "Salz, Rich"  skrev:
>> Really, how?  By pull request, you mean one against the openssl
>github
>> account so people subscribing to that account see it, I presume?  For
>that to
>> happen, the tree the patch is against must actually exist within the
>account,
>> which this one doesn't.
>
>You clone the openssl git repo, create your own branch off master,
>apply the diffs you are mailing to the list, and commit/push and then
>make a PR.  Yes it's a bit of work for you.  But it then becomes
>near-zero work for anyone on openssl to look at it.
>
>> This patch is mostly FYI, so yes, I do given that multiple mailing
>lists have
>> some interest.
>
>It's all about trade-offs.  Multiple people have said multiple times
>that PR's are the best way to work with OpenSSL.  If those other
>groups, individually or collectively, are higher on your priority list,
>that's fine.  But do understand what's going on.
>
>> I'm still waiting on a reply ... I assume holidays are contributing
>to the delay.
>> However, openssl_tpm_engine is a DCO project, so that concern is
>irrelevant
>> here.
>
>Sorry, I'll push to get the bylaws made public, is that what you need?
>
>And no, it's not irrelevant.  If this is ever going to appear in
>OpenSSL, a CLA must be signed.
>
>-- 
>openssl-dev mailing list
>To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
-- 
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev