Re: [TLS] TLS RSA-PSS and various versions of TLS

[Ilari Liusvaara]

On Wed, Apr 26, 2017 at 03:23:57PM +0200, Martin Rex wrote:
> 
> Signatures on certificates are created by CAs, rather than TLS endpoints,
> so any implementation that uses TLS protocol parameters (about TLS signature
> algorithms) for more than a mere cert selection hint, is actively creating
> interop problems while providing *NO* value.  Many TLS peers will have
> just one suitable certificate anyway, so not even looking at certificate
> signatures will be the easiest to implement, most robust and perfectly secure
> behaviour anyway.

What my implementation does with certificate signatures:
- There actually are signature algorithms with no known TLS code, e.g.
  ECDSA-SHA3 signatures. These are known but can not be advertised.
- The built-in server-side certificate selection code never selects
  certificate containing algorithm client didn't advertise.
- The server side certificate chain checking interlocks on unknown
  signature algorithms, but not unadvertised signature algorithms. So
  custom certificate selector can overrule the client advertisment, but
  not known algorithm check.
- On client side, all known algorithms (other than PKCS#1/SHA-1, which
  is treated specially) are treated as valid for certificates. Advertised
  or not. All others are just ignored (which violates a MUST in spec)
  and path building never builds through those..
- Regarding RSA-PSS, only the 3 variants that TLS defines are supported).


> The issue with RSA-PSS digital signatures is that they were defined
> with additional (unnecessary) parameters that are encoded (=hidden) in the
> ASN.1 AlgorithmIdentifier, and that are therefore unspecified when
> RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1
> AlgorithmIdentifier.

TLS 1.3 specifies what values those parameters have for various
SignatureSchemes.
 
> The additional, unnecessary parameters are "saltLen" and
> "MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction
> (mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).

Also specified.

> In theory there is another additional, unnecessary parameter "TrailerField",
> which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the
> XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially
> hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc.

So this also counts as specified.

> 
> The definition of "implied" RSA-PSS parameters applies only to the
> "digitally-signed" signature blobs using inside the TLS protocol
> because these do not come with an ASN.1 AlgorithmIdentifier tag.
> The implied RSA-PSS paramters for TLS' digitally-signed are unrelated
> to RSA-PSS signatures on certificates (certificates come with explicit
> RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer):
> 
>Certificate  ::=  SEQUENCE  {
> tbsCertificate   TBSCertificate,
> signatureAlgorithm   AlgorithmIdentifier,
> signatureValue   BIT STRING  }
> 
> The original RSA-PSS AlgorithmIdentifer specification also defines
> a hierarchical policy concept, that is supposed to limit the kinds
> of signatures that can be created (verified) with a so-tagged public
> RSA key, and this policy is supposed to work/apply from the RootCA cert
> *downwards* to the leaf / end-entity cert.

I don't think it appiles that way, only per-key.

ExtendedKeyUsage is *not* supposed to be hierarchial, but doesn't
prevent many libraries from handling it that way.

> It seems silly trying to apply implied RSA-PSS parameter selections
> from the digitally-signed TLS protocol transform to the signature
> on the TLS end-entity cert (or worse, even to certs up the cert chain),
> because that would be the wrong/invalid direction.

The SignatureScheme selections only mean those schemes are supported,
not that other RSA-PSS schemes can't be supported in CA signatures
(however, there is no way to advertise those).

> What should be spelled out, whether and how any RSA-PSS policy in the
> subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate
> interacts with implied RSA-PSS parameters used by the TLS digitally-signed
> transform.  In any case, the decision whether to accept a certificate
> should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender.

AFAIK, the only place there is any impiled interaction is when the end-
entity key is RSA-PSS-only. And there the rules are usual matching rules
versus the key.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Martin Rex]

Dr Stephen Henson wrote:
> On 25/04/2017 15:36, Benjamin Kaduk wrote:
>> 
>>RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
>>   PSS [RFC3447 ] with mask 
>> generation function 1.  The digest used in
>>   the mask generation function and the digest being signed are both
>>   the corresponding hash algorithm as defined in [SHS 
>> ].  When used
>>   in signed TLS handshake messages, the length of the salt MUST be
>>   equal to the length of the digest output.  This codepoint is also
>>   defined for use with TLS 1.2.
>> 
>> 
>> Is the concern that this is insufficiently clearly indicated as placing
>> requirements on signatures of certificates as opposed to signatures of
>> TLS data structures?
> 
> Yes that's my concern. Supporting PSS signatures on certificates is
> a mandatory requirement and I think we should be very clear about the
> parameters we permit.
> 
> The above paragraph says nothing about salt length limitations on
> signatures on certificates. We could have a situation where one
> implementation enforces the salt length to be equal to the digest length
> (and rejects everything else) and another will allow any valid length.


It has always been a terribly stupid bug that TLS started talking about
signatures on certificates when negotiating TLS protocol properties,
and it resulted in a few painfully broken TLSv1.2 implementations getting
shipped (such as Microsoft Windows7/2008R2 through 8.1/2012R2).

Please ensure that TLSv1.3 is cleaned from bogus references about
requirements on signature algorithms for certificates.

Signatures on certificates are created by CAs, rather than TLS endpoints,
so any implementation that uses TLS protocol parameters (about TLS signature
algorithms) for more than a mere cert selection hint, is actively creating
interop problems while providing *NO* value.  Many TLS peers will have
just one suitable certificate anyway, so not even looking at certificate
signatures will be the easiest to implement, most robust and perfectly secure
behaviour anyway.


The issue with RSA-PSS digital signatures is that they were defined
with additional (unnecessary) parameters that are encoded (=hidden) in the
ASN.1 AlgorithmIdentifier, and that are therefore unspecified when
RSA-PSS is requested as (rsa-pss,sha-256) rather than with an ASN.1
AlgorithmIdentifier.

The additional, unnecessary parameters are "saltLen" and
"MaskGenerationFunction" (MGF), and the commonly-used MaskGenerationFunction
(mgf1) adds yet another additional, unnecessary parameter (MGF-internal hash).


In theory there is another additional, unnecessary parameter "TrailerField",
which appears in the ASN.1 AlgorithmIdentifier parameter list (and in the
XMLdsig encoding for RSA-PSS), but PKCS#1 v2.1 (rfc3447) essentially
hardwires the Trailerfield to option TrailerfieldBC(1), internal value 0xbc.


The definition of "implied" RSA-PSS parameters applies only to the
"digitally-signed" signature blobs using inside the TLS protocol
because these do not come with an ASN.1 AlgorithmIdentifier tag.
The implied RSA-PSS paramters for TLS' digitally-signed are unrelated
to RSA-PSS signatures on certificates (certificates come with explicit
RSA-PSS parameters encoded in an ASN.1 AlgorithmIdentifer):

   Certificate  ::=  SEQUENCE  {
tbsCertificate   TBSCertificate,
signatureAlgorithm   AlgorithmIdentifier,
signatureValue   BIT STRING  }

The original RSA-PSS AlgorithmIdentifer specification also defines
a hierarchical policy concept, that is supposed to limit the kinds
of signatures that can be created (verified) with a so-tagged public
RSA key, and this policy is supposed to work/apply from the RootCA cert
*downwards* to the leaf / end-entity cert.

It seems silly trying to apply implied RSA-PSS parameter selections
from the digitally-signed TLS protocol transform to the signature
on the TLS end-entity cert (or worse, even to certs up the cert chain),
because that would be the wrong/invalid direction.


What should be spelled out, whether and how any RSA-PSS policy in the
subjectPublicKeyInfo AlgorithmIdentifier of the end-entity certificate
interacts with implied RSA-PSS parameters used by the TLS digitally-signed
transform.  In any case, the decision whether to accept a certificate
should be _with_the_receiver_ (verifier / RP), and *NEVER* with the sender.


-Martin

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Dr Stephen Henson]

On 25/04/2017 15:36, Benjamin Kaduk wrote:
> On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
>> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>>> certificates too?
>>>
>>> For example could a TLS 1.2 server legally present a certificate containing 
>>> an
>>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
>>> present
>>> a certificate contain an RSASSA-PSS key?
>>>
>> I can't recall getting a definitive answer to this. IMHO we should make the
>> requirements clear in the spec otherwise we could get interop issues.
>>
>> Based on the opinions stated in this thread that would be:
>>
>> 1. When PSS signatures appear certificates, MGF digest and signing digest 
>> MUST
>> match and the salt length must equal the digest length.
> 
> We have (in section 4.2.3, Signature Algorithms):
> 
>RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
>   PSS [RFC3447 ] with mask 
> generation function 1.  The digest used in
>   the mask generation function and the digest being signed are both
>   the corresponding hash algorithm as defined in [SHS 
> ].  When used
>   in signed TLS handshake messages, the length of the salt MUST be
>   equal to the length of the digest output.  This codepoint is also
>   defined for use with TLS 1.2.
> 
> 
> Is the concern that this is insufficiently clearly indicated as placing 
> requirements on signatures of certificates as opposed to signatures of TLS 
> data structures?
> 

Yes that's my concern. Supporting PSS signatures on certificates is a mandatory
requirement and I think we should be very clear about the parameters we permit.

The above paragraph says nothing about salt length limitations on signatures on
certificates. We could have a situation where one implementation enforces the
salt length to be equal to the digest length (and rejects everything else) and
another will allow any valid length.

> 
> 
>> 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys 
>> MUST
>> be supported both as server keys and CA keys in certificates.
> 
> Similarly to (1), I believe that it is possible to read the existing 
> (draft-19)
> text as making these requirements already, so is the concern that the text 
> needs
> to be more clear?
> 

Yes. id-RSASSA-PSS isn't mentioned anywhere in the spec. If we require
implementations to support this I think we should be explicit about it.

We might want to refer to RFC5756/RFC4055 which document the syntax.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Benjamin Kaduk]

On 04/25/2017 07:08 AM, Dr Stephen Henson wrote:
> On 18/02/2017 02:31, Dr Stephen Henson wrote:
>> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
>> certificates too?
>>
>> For example could a TLS 1.2 server legally present a certificate containing 
>> an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
>> present
>> a certificate contain an RSASSA-PSS key?
>>
> I can't recall getting a definitive answer to this. IMHO we should make the
> requirements clear in the spec otherwise we could get interop issues.
>
> Based on the opinions stated in this thread that would be:
>
> 1. When PSS signatures appear certificates, MGF digest and signing digest MUST
> match and the salt length must equal the digest length.

We have (in section 4.2.3, Signature Algorithms):

   RSASSA-PSS algorithms  Indicates a signature algorithm using RSASSA-
  PSS [RFC3447 ] with mask generation 
function 1.  The digest used in
  the mask generation function and the digest being signed are both
  the corresponding hash algorithm as defined in [SHS 
].  When used
  in signed TLS handshake messages, the length of the salt MUST be
  equal to the length of the digest output.  This codepoint is also
  defined for use with TLS 1.2.


Is the concern that this is insufficiently clearly indicated as placing 
requirements on signatures of certificates as opposed to signatures of TLS data 
structures?



> 2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys 
> MUST
> be supported both as server keys and CA keys in certificates.

Similarly to (1), I believe that it is possible to read the existing
(draft-19) text as making these requirements already, so is the concern
that the text needs to be more clear?


> 3. PSS only keys MUST be supported for TLS 1.2 also.
>

Section 1.3, "Updates Affecting TLS 1.2" notes:

   [...]
   -  RSASSA-PSS signature schemes are defined in Section 4.2.3
.

   An implementation of TLS 1.3 that also supports TLS 1.2 might need to
   include changes to support these changes even when TLS 1.3 is not in
   use.  See the referenced sections for more details.


-Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Dr Stephen Henson]

On 18/02/2017 02:31, Dr Stephen Henson wrote:
> 
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
> 
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
> present
> a certificate contain an RSASSA-PSS key?
> 

I can't recall getting a definitive answer to this. IMHO we should make the
requirements clear in the spec otherwise we could get interop issues.

Based on the opinions stated in this thread that would be:

1. When PSS signatures appear certificates, MGF digest and signing digest MUST
match and the salt length must equal the digest length.

2. Indicate that the PSS only (id-RSASSA-PSS) and RSA (rsaEncryption) keys MUST
be supported both as server keys and CA keys in certificates.

3. PSS only keys MUST be supported for TLS 1.2 also.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Hubert Kario]

On Saturday, 18 February 2017 18:22:23 CET Dr Stephen Henson wrote:
> On 18/02/2017 16:26, Viktor Dukhovni wrote:
> > On Sat, Feb 18, 2017 at 02:31:19AM +, Dr Stephen Henson wrote:
> >> For example could a TLS 1.2 server legally present a certificate
> >> containing an RSASSA-PSS key for an appropriate ciphersuite? Similarly
> >> could a client present a certificate contain an RSASSA-PSS key?
> > 
> > Isn't an RSA public key independent of the signature algorithms it
> > might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> > is not negotiated, can't the peer (client or server) just sign with
> > PKCS#1?  So the same EE cert would then be valid for either PSS or
> > PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
> 
> The most commonly deployed certificates containing RSA keys use
> rsaEncryption (1 2 840 113549 1 1 1). For those the key can be used for
> PKCS#1 and PSS.
> 
> There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With
> that OID the key can only be legally used for PSS (with possible additional
> restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable
> for TLS before 1.3 as the signature was always PKCS#1. As a result very few
> such certificates have been seen in the wild, but (as mentioned in other
> threads) they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory
> algorithm).

sorry for the slight off-topic: how can you create such certificates with 
openssl command line util?

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Martin Thomson]

On 19 February 2017 at 06:25, Ilari Liusvaara  wrote:
> - Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in
>   1.2 and certificates.
> - When using RSA-PSS for SKE signature, the ciphersuite signature
>   algorithm is set to RSA.
> - Ciphersuite signature algorithm is ignored on receipt.
> - RSA-PSS SKE signatures are recognized from hash=8, algoritm=4, 5 or
>   6 in DigitallySigned algorithm. The hash is determined from the
>   algorithm number.
> - RSA-PSS certificate signatures are recognized by exact match to
>   precomposed algorithmidentifier values.
> - RsaEncryption keys can be used to validate RSA-PKCS#1 v1.5 and
>   RSA-PSS signatures.
> - RSA-PSS keys can be used to validate RSA-PSS only, not RSA-PKCS#1
>   v1.5.
> - Normally, any server RSA keys need to be RsaEncryption type, but
>   it is possible to force RSA-PSS key by some tricks..
> - If client indicated support for both RSA-PKCS#1 v1.5 and RSA-PSS
>   and RSA key is selected, RSA-PSS is preferred.

NSS does all of this too.  With the only difference being in server
configuration.  Server RSA keys are used for PKCS#1 and PSS if they
are of the rsaEncryption type, and RSA-PSS keys - as determined by the
OID in the certificate SPKI - are only used for PSS.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Ilari Liusvaara]

On Sat, Feb 18, 2017 at 06:22:23PM +, Dr Stephen Henson wrote:
> On 18/02/2017 16:26, Viktor Dukhovni wrote:
> > On Sat, Feb 18, 2017 at 02:31:19AM +, Dr Stephen Henson wrote:
> > 
> >>
> >> For example could a TLS 1.2 server legally present a certificate 
> >> containing an
> >> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
> >> present
> >> a certificate contain an RSASSA-PSS key?
> > 
> > Isn't an RSA public key independent of the signature algorithms it
> > might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> > is not negotiated, can't the peer (client or server) just sign with
> > PKCS#1?  So the same EE cert would then be valid for either PSS or
> > PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
> > 
> 
> The most commonly deployed certificates containing RSA keys use rsaEncryption 
> (1
> 2 840 113549 1 1 1). For those the key can be used for PKCS#1 and PSS.
> 
> There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With 
> that
> OID the key can only be legally used for PSS (with possible additional
> restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable for
> TLS before 1.3 as the signature was always PKCS#1. As a result very few such
> certificates have been seen in the wild, but (as mentioned in other threads)
> they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory algorithm).
> 
> My question was whether this implied TLS 1.2 implementations (that include PSS
> in the signature algorithms extension) must support them too.

The behaviour of implementation I have been writing in regards to
RSA-PSS:

- Only the 3 TLS 1.3 variants of RSA-PSS are supported. Including in
  1.2 and certificates.
- When using RSA-PSS for SKE signature, the ciphersuite signature
  algorithm is set to RSA.
- Ciphersuite signature algorithm is ignored on receipt.
- RSA-PSS SKE signatures are recognized from hash=8, algoritm=4, 5 or
  6 in DigitallySigned algorithm. The hash is determined from the
  algorithm number.
- RSA-PSS certificate signatures are recognized by exact match to
  precomposed algorithmidentifier values.
- RsaEncryption keys can be used to validate RSA-PKCS#1 v1.5 and
  RSA-PSS signatures.
- RSA-PSS keys can be used to validate RSA-PSS only, not RSA-PKCS#1
  v1.5.
- Normally, any server RSA keys need to be RsaEncryption type, but
  it is possible to force RSA-PSS key by some tricks..
- If client indicated support for both RSA-PKCS#1 v1.5 and RSA-PSS
  and RSA key is selected, RSA-PSS is preferred.


Nearly all of this just falls from the TLS 1.3 support. The only
version-specific part is knowing to set RSA certificate algorithm if
RSA-PSS was chosen (and this is controlled by one bitmask)..


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Dr Stephen Henson]

On 18/02/2017 16:26, Viktor Dukhovni wrote:
> On Sat, Feb 18, 2017 at 02:31:19AM +, Dr Stephen Henson wrote:
> 
>>
>> For example could a TLS 1.2 server legally present a certificate containing 
>> an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
>> present
>> a certificate contain an RSASSA-PSS key?
> 
> Isn't an RSA public key independent of the signature algorithms it
> might be employed with?  If the EE cert has an RSA key, and RSA-PSS
> is not negotiated, can't the peer (client or server) just sign with
> PKCS#1?  So the same EE cert would then be valid for either PSS or
> PKCS#1?  Or have I missed the memo on how PSS works with EE certs?
> 

The most commonly deployed certificates containing RSA keys use rsaEncryption (1
2 840 113549 1 1 1). For those the key can be used for PKCS#1 and PSS.

There is however a second OID id-RSASSA-PSS defined in RFC4055 et al. With that
OID the key can only be legally used for PSS (with possible additional
restrictions) and not PKCS#1. That algorithm OID in EE certs was unusable for
TLS before 1.3 as the signature was always PKCS#1. As a result very few such
certificates have been seen in the wild, but (as mentioned in other threads)
they MUST be supported in TLS 1.3 (rsa_pss_sha256 is a mandatory algorithm).

My question was whether this implied TLS 1.2 implementations (that include PSS
in the signature algorithms extension) must support them too.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Viktor Dukhovni]

On Sat, Feb 18, 2017 at 02:31:19AM +, Dr Stephen Henson wrote:

> > If client includes RSA-PSS codepoints in its signature_algorithms,
> > then:
> > 
> > - The server handshake signature MAY be signed using RSA-PSS in TLS
> >   1.2 or later. Yes, 1.2, not 1.3.
> > - The certificate chain MAY contain certificates signed with RSA-PSS
> >   in any TLS version (however, the salt length must match hash length).
> > 
> > In converse case:
> > 
> > - The server MUST NOT sign handshake using RSA-PSS in any TLS
> >   version
> > - The certificate chain SHOULD NOT contain certificates signed with
> >   RSA-PSS in any TLS version.
> > 
> 
> Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
> certificates too?
> 
> For example could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
> present
> a certificate contain an RSASSA-PSS key?

Isn't an RSA public key independent of the signature algorithms it
might be employed with?  If the EE cert has an RSA key, and RSA-PSS
is not negotiated, can't the peer (client or server) just sign with
PKCS#1?  So the same EE cert would then be valid for either PSS or
PKCS#1?  Or have I missed the memo on how PSS works with EE certs?

As for the signatures in the X.509 chain itself, the "SHOULD NOT"
above just means that we have a non-PSS chain to offer, then we
offer that, but if PSS is all we have, then present that chain.

Fundamentally, X.509 verification lies outside of TLS, and it is
not the job of TLS to second-guess the X.509 stacks on either end.
The peers can provide hints about preferred/supported algorithms,
but in the case of X.509 these are not hard constraints.  The X.509
algorithm hints in TLS are about increasing the chances of
interoperability, and not excluding unadvertised codepoints.

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Dr Stephen Henson]

On 18/02/2017 10:01, Martin Thomson wrote:
> On 18 February 2017 at 13:31, Dr Stephen Henson
>  wrote:
>> could a TLS 1.2 server legally present a certificate containing an
>> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
>> present
>> a certificate contain an RSASSA-PSS key?
> 
> NSS, when configured to do so, will do just that.  I wouldn't
> recommend it right now, but it is legal.  Actually, if you offer
> support for validating PSS and end up negotiating 1.2, then you should
> be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3
> spec.
> 
> 

The reason I wasn't sure about this is that for TLS 1.2 the server certificate
key algorithm is associated with a ciphersuite. So for example the "RSA" in
TLS_DH_RSA_WITH_AES_256_CBC_SHA256 would previously refer to the OID
rsaEncryption (1 2 840 113549 1 1 1) if PSS is included in signature algorithms
it could also refer to id-RSASSA-PSS.

Similarly for client certificates there is the ClientCertificateType rsa_sign
though RFC5246 just says "a certificate containing an RSA key".

I'd be curious to know what other implementations do. I suggest we make this
possibility clear in the spec, along with the salt length in certificate
signatures previously discussed. Otherwise it isn't inconceivable that some will
reject id-RSASSA-PSS keys in end entity certificates in TLS 1.2.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Martin Thomson]

On 18 February 2017 at 13:31, Dr Stephen Henson
 wrote:
> could a TLS 1.2 server legally present a certificate containing an
> RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client 
> present
> a certificate contain an RSASSA-PSS key?

NSS, when configured to do so, will do just that.  I wouldn't
recommend it right now, but it is legal.  Actually, if you offer
support for validating PSS and end up negotiating 1.2, then you should
be prepared to receive PSS signatures.  It's a wee gotcha in the 1.3
spec.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Dr Stephen Henson]

On 08/02/2017 21:17, Ilari Liusvaara wrote:
> On Wed, Feb 08, 2017 at 07:34:16PM +, Timothy Jackson wrote:
>> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
>> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
>> apply only to the signatures that can be used for signing handshakes or
>> does it apply to the entire certificate chain as well? I ask because while
>> I think the latter may have been the intent I have not found anything that
>> indicates the former is not actually what the RFCs require.
>>
>> The relevant section of RFC4056 reads:
>>
>> 7.4.2 Server Certificate
>> …
>> Note that there are certificates that use algorithms and/or algorithm
>>combinations that cannot be currently used with TLS.  For example, a
>>certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
>>SubjectPublicKeyInfo) cannot be used because TLS defines no
>>corresponding signature algorithm.
>>
>> I don’t see anything here that restricts which signatures can be used on
>> the certificates themselves. Is that accurate? If so, then I think the
>> relevant restrictions are not in TLS RFCs at all, but rather are in RFCs
>> such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it
>> therefore permissible to have a CA that is signed with RSASSA-PSS with
>> TLS 1.0, 1.1, or 1.2.
>>
>> Is this what was intended?
> 
> My interpretation:
> 
> If client includes RSA-PSS codepoints in its signature_algorithms,
> then:
> 
> - The server handshake signature MAY be signed using RSA-PSS in TLS
>   1.2 or later. Yes, 1.2, not 1.3.
> - The certificate chain MAY contain certificates signed with RSA-PSS
>   in any TLS version (however, the salt length must match hash length).
> 
> In converse case:
> 
> - The server MUST NOT sign handshake using RSA-PSS in any TLS
>   version
> - The certificate chain SHOULD NOT contain certificates signed with
>   RSA-PSS in any TLS version.
> 

Does this apply to RSASSA-PSS (RSA-PSS signing only) keys in end entity
certificates too?

For example could a TLS 1.2 server legally present a certificate containing an
RSASSA-PSS key for an appropriate ciphersuite? Similarly could a client present
a certificate contain an RSASSA-PSS key?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: shen...@drh-consultancy.co.uk, PGP key: via homepage.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Martin Thomson]

On 9 February 2017 at 08:17, Ilari Liusvaara  wrote:
> If client includes RSA-PSS codepoints in its signature_algorithms,
> then:
>
> - The server handshake signature MAY be signed using RSA-PSS in TLS
>   1.2 or later. Yes, 1.2, not 1.3.
> - The certificate chain MAY contain certificates signed with RSA-PSS
>   in any TLS version (however, the salt length must match hash length).


This is consistent with TLS 1.3 (and the discussion we had on the same
subject previously).

RSASSA-PSS algorithms: Indicates a signature algorithm using
RSASSA-PSS [RFC3447] with mask generation function 1. The digest used
in the mask generation function and the digest being signed are both
the corresponding hash algorithm as defined in [SHS]. When used in
signed TLS handshake messages, the length of the salt MUST be equal to
the length of the digest output. This codepoint is also defined for
use with TLS 1.2.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Ilari Liusvaara]

On Wed, Feb 08, 2017 at 07:34:16PM +, Timothy Jackson wrote:
> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with
> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS
> apply only to the signatures that can be used for signing handshakes or
> does it apply to the entire certificate chain as well? I ask because while
> I think the latter may have been the intent I have not found anything that
> indicates the former is not actually what the RFCs require.
> 
> The relevant section of RFC4056 reads:
> 
> 7.4.2 Server Certificate
> …
> Note that there are certificates that use algorithms and/or algorithm
>combinations that cannot be currently used with TLS.  For example, a
>certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
>SubjectPublicKeyInfo) cannot be used because TLS defines no
>corresponding signature algorithm.
> 
> I don’t see anything here that restricts which signatures can be used on
> the certificates themselves. Is that accurate? If so, then I think the
> relevant restrictions are not in TLS RFCs at all, but rather are in RFCs
> such as 4055, 4056, and 5756. These RFCs allow RSASSA-PSS. Is it
> therefore permissible to have a CA that is signed with RSASSA-PSS with
> TLS 1.0, 1.1, or 1.2.
> 
> Is this what was intended?

My interpretation:

If client includes RSA-PSS codepoints in its signature_algorithms,
then:

- The server handshake signature MAY be signed using RSA-PSS in TLS
  1.2 or later. Yes, 1.2, not 1.3.
- The certificate chain MAY contain certificates signed with RSA-PSS
  in any TLS version (however, the salt length must match hash length).

In converse case:

- The server MUST NOT sign handshake using RSA-PSS in any TLS
  version
- The certificate chain SHOULD NOT contain certificates signed with
  RSA-PSS in any TLS version.


-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Martin Thomson]

On 9 February 2017 at 07:20, Yoav Nir  wrote:
> And it doesn’t help if the client does not provide the extension.  The
> extension can restrict from among the set of supported algorithms, Its
> absence does not allow undefined algorithms.

Since TLS 1.3 defines code points for RSA-PSS, perhaps this is no
longer accurate - at least for PSS.

NSS supports PSS signatures in TLS 1.2.  It caused a small amount of
compatibility pain deploying them thanks to some infrequently used,
but overzealous implementations.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS RSA-PSS and various versions of TLS

[Yoav Nir]

> On 8 Feb 2017, at 21:34, Timothy Jackson  wrote:
> 
> I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with 
> RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS 
> apply only to the signatures that can be used for signing handshakes or does 
> it apply to the entire certificate chain as well? I ask because while I think 
> the latter may have been the intent I have not found anything that indicates 
> the former is not actually what the RFCs require.
> 
> The relevant section of RFC4056 reads:
> 
> 7.4.2 Server Certificate
> …
> Note that there are certificates that use algorithms and/or algorithm
>combinations that cannot be currently used with TLS.  For example, a
>certificate with RSASSA-PSS signature key (id-RSASSA-PSS OID in
>SubjectPublicKeyInfo) cannot be used because TLS defines no
>corresponding signature algorithm.
> 
> I don’t see anything here that restricts which signatures can be used on the 
> certificates themselves. Is that accurate?

No.  A few paragraphs up:

   If the client provided a "signature_algorithms" extension, then all
   certificates provided by the server MUST be signed by a
   hash/signature algorithm pair that appears in that extension.

And it doesn’t help if the client does not provide the extension.  The 
extension can restrict from among the set of supported algorithms, Its absence 
does not allow undefined algorithms.

Yoav



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls