Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
On 12/09/2017 15:10, Nikos Mavrogiannopoulos wrote: > > That is, because a TLS server would typically sign with whatever > algorithm the client supports and would very rarely be interested to > utilize the security advantages of including the parameters (which, > advantages, are quite unclear even to a crypto expert). Otherwise, a > certificate restricted to SHA-384 and 48-bytes of salt, will not be > able to serve a client which only supports RSASSA-PSS with SHA-256. > > As such, it would make sense for TLS 1.3 to recommend no parameters for > such RSASSA-PSS certificates, to ease their deployment. > Well restrictions in CA keys would be handled by the PKI verifier: if there is a violation the chain should be rejected and it's a problem with the chain itself and an error by the CA that issued it. A different case is where the restrictions are legal from a PKIX standpoint but not allowed by TLS 1.3, though again it's a CA error issuing such a chain for TLS 1.3 use. A restriction on the EE key isn't quite the same. There are two cases. One is that the parameters are not permitted by TLS 1.3 at all (e.g. MGF1 digest doesn't match signing digest or minimum salt length exceeds digest length). In this case a server should never present the chain or if it does a client would justifiably reject it and abort the handshake. Again this is an error by the issuing authority which should be corrected. The second case is that the parameter restriction is permitted by TLS 1.3 and this limits the digest which the key can sign with. Say the restriction is SHA384 and the client only supports rsa_pss_sha256. The server might then use to a different PSS key (and certificate chain) that supports rsa_pss_sha256 or fall back to an RSA key to use rsa_pss_sha256. Again if a client sees a TLS message signed with parameters that violate the restrictions it could (with some justification) abort the handshake. This could get pretty messy: it requires a logic not used in any other algorithm. I'd be more than happy to have an outright prohibition on EE PSS key parameter restrictions in TLS 1.3 so implementers don't have to bother with this. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
On 11/09/2017 19:42, Eric Rescorla wrote: > Ugh. > > Generally, the idea with signature schemes is that they are supposed to > reflect > both the capabilities of your TLS stack and the capabilities of your PKI > verifier [0]. So, yes, if you advertise this it is supposed to work. So, > ideally > we would just say that it's as Ilari says in his followup. > > It seems like there are really two choices: > > 1. Only advertise algorithm X if you support algorithm X in both places > 2. Invent a new extension whose semantics are "if present, this tells you what > the PKI validator accepts, otherwise look at signature schemes" > > I hate to be suggesting #2 at this stage in the process, but maybe it's right > anyway... > It's rather more than just certificate signatures. The problem here is that there is no way to indicate an implementation supports rsaEncryption keys but not RSASSA-PSS keys and the current draft requires that implementations support both AFAICS. RSASSA-PSS keys are pretty rare at the moment. There are some complications involved with supporting them not present with other key types: more complex parameter sets and key restrictions for example. Implementors might feel (despite what the draft says) that the added complexity is not justified because no one will ever want to use RSASSA-PSS keys. At the same time if important implementations abort the handshake when they see an RSASSA-PSS key then this is a strong reason for a server to not deploy RSASSA-PSS keys: it will cause interoperability issues. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] RSASSA-PSS in certificates and "signature_algorithms"
On 08/09/2017 23:59, Peter Wu wrote: > > In particular, for certificates: > > - Limitations on salt length? > - What AlgorithmIdentifier OID to use? > - Whether to constrain other AlgorithmIdentifier Params? (MGF, hash >algorithm, trailerField)? > Note that you have to check any PSS restrictions in the certificates themselves too. For signatures on certificates this should be handled as part of the normal chain validation process. For restrictions on the EE key this would add additional complications on the digests the key can sign with in the handshake. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consistency for Signature Algorithms?
On 21/07/2017 16:00, Ilari Liusvaara wrote: > > I suppose some new dual-version TLS 1.2/1.3 libraries might have the > same issue as mine: supported groups is just plain ignored for ECDSA, > and siganture algorithms have the TLS 1.3 meanings, even in TLS 1.2. > That is potentially a problem yes. Suppose a server has an EE certificate with a P-256 public key and the client preference order is ecdsa_secp384r1_sha384, ecdsa_secp256r1_sha256. For TLS 1.3 it will use ecdsa_secp256r1_sha256 and sign TLS messages using P-256+SHA256. In TLS 1.2 the same preference list means sha384+ecdsa, sha256+ecdsa without the curve restriction. In this case the server might sign the message using P-256+SHA384 because the client prefers it. That isn't allowed in TLS 1.3 but is in TLS 1.2. A client which enforces the TLS 1.3 signature algorithm rules for TLS 1.2 might abort the connection at that point. >> I agree though that there is an anomaly here. For example AFAICS in >> certificates for TLS1.3 you're allowed (with some caveats) to use a >> P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not >> allowed at all. Is that likely to be a problem in practice? Are there many >> such certificates about in the wild? > > Actually, P-256+SHA512 is allowed with a caveat, even if the > certificate is not self-signed. And with the same caveat, server can > send a certificate signed with P-256+SHA3-512, despite TLS > codepoint for it having never existed (not many clients can validate it > through). > Yes you're right, the caveat of not otherwise having any suitable chain allows that case. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consistency for Signature Algorithms?
-- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ On 21/07/2017 20:45, Dr Benjamin Kaduk wrote: > On 07/21/2017 08:41 AM, Dr Stephen Henson wrote: >> On 21/07/2017 14:23, Hubert Kario wrote: >>> Signature Algorithms for ECDSA now define both the curve and the hash >>> algorithm: >>> >>> ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), >>> ecdsa_secp521r1_sha512(0x0603), >>> >>> This is in contrast to the TLS 1.2 protocol, where any hash can be used >>> with any curve. >>> >>> There are good reasons for that change: - less combinations to test - >>> establishes the low water mart for security >>> >>> I see few problems with that though: 1). there are not insignificant number >>> of clients that advertise support for all (at least P-256 and P-384) >>> curves, but don't advertise support for hashes stronger than SHA-256 with >>> ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is >>> completely detached from the used hash algorithm. 3). This is not how ECDSA >>> signatures in X.509 work, so it doesn't actually limit the signatures on >>> certificates (in other words, as an implementer you need to support all >>> hashes with all curves either way) >>> >> There is another and significant problem with the change. In TLS 1.2 support >> for a curve was indicated in the supported curves extension and it implied >> support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the >> supported groups extension are for ECDH only. Support for a curve for ECDSA >> is >> indicated in the signature algorithms extension. > > Could you say a bit more about why you believe this to be a problem? On the > face of it, it seems that the previous state overloaded a single field to mean > multiple only semi-related things, whereas the new formulation keeps things > more > orthogonal and easier to implement in a modular way. That is, groups are for > key exchange, and signature algorithms are for signing, and there is no muddy > overlap between them. > I didn't mean there was a problem with the current spec, I meant there was a problem with the proposed change: i.e. to remove the curve requirement from signature algorithms. Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Consistency for Signature Algorithms?
On 21/07/2017 14:23, Hubert Kario wrote: > Signature Algorithms for ECDSA now define both the curve and the hash > algorithm: > > ecdsa_secp256r1_sha256(0x0403), ecdsa_secp384r1_sha384(0x0503), > ecdsa_secp521r1_sha512(0x0603), > > This is in contrast to the TLS 1.2 protocol, where any hash can be used > with any curve. > > There are good reasons for that change: - less combinations to test - > establishes the low water mart for security > > I see few problems with that though: 1). there are not insignificant number > of clients that advertise support for all (at least P-256 and P-384) > curves, but don't advertise support for hashes stronger than SHA-256 with > ECDSA[1] 2). This is inconsistent with RSA-PSS behaviour, where key size is > completely detached from the used hash algorithm. 3). This is not how ECDSA > signatures in X.509 work, so it doesn't actually limit the signatures on > certificates (in other words, as an implementer you need to support all > hashes with all curves either way) > There is another and significant problem with the change. In TLS 1.2 support for a curve was indicated in the supported curves extension and it implied support for ECDH and ECDSA. This has changed in TLS 1.3: curves in the supported groups extension are for ECDH only. Support for a curve for ECDSA is indicated in the signature algorithms extension. I agree though that there is an anomaly here. For example AFAICS in certificates for TLS1.3 you're allowed (with some caveats) to use a P-256+SHA-1 signature (which has security concerns) but P-256 + SHA512 is not allowed at all. Is that likely to be a problem in practice? Are there many such certificates about in the wild? Steve. -- Dr Stephen N. Henson. Founder member of the OpenSSL project: http://www.openssl.org/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLS RSA-PSS and various versions of TLS
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 <https://tools.ietf.org/html/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 > <https://tools.ietf.org/html/draft-ietf-tls-tls13-19#ref-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
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] WGLC: draft-ietf-tls-tls13-19
On 27/03/2017 08:47, Olivier Levillain wrote: > > For a longer version, post-handshake records of type Handshake can be of > three kinds: > - NewSessionTicket (sent by the server, and that can safely be ignored > entirely by clients) > - KeyUpdate (sent by either party, requiring only a bit of state) > - CertificateRequest (sent by the server, an arbirary number of times, > and requring the client to keep some state *for each request*) > > Of course, this last item makes the post-handshake client state machine > explode, whereas the first two items can ben implemented in a trivial > way. The client can not indeed ignore all this state to answer, since it > is supposed to answer at least with a Finished message, which will cover > the CertificateRequest message. Moreover, since each of these Finished > messages must cover the initial handshake and the current > CertificateRequest message, it requires a forkable hash implementation, > which requires more memory. > To me allowing the server to send multiple certificate request messages and the client being permitted to respond to them in arbitrary order adds quite a bit of complexity. Is there a usage scenario for this? Would permitting only one outstanding Certificate Request be too limiting? On a related note in 4.6.2: Note: Because client authentication may require prompting the user, servers MUST be prepared for some delay, including receiving an arbitrary number of other messages between sending the CertificateRequest and receiving a response. I'm assuming that once the client has responded with a Certificate message it MUST send CertificateVerify and Finished afterwards and nothing else is permissible? That is it can't send application data or respond to other outstanding CertificateRequest messages? 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] (no subject)
On 09/02/2017 21:17, Eric Rescorla wrote: > Hi folks, > > We need to close on an issue about the size of the > state in the HelloRetryRequest. Because we continue the transcript > after HRR, if you want a stateless HRR the server needs to incorporate > the hash state into the cookie. However, this has two issues: > > 1. The "API" for conventional hashes isn't designed to be checkpointed >at arbitrary points (though PKCS#11 at least does have support >for this.) > 2. The state is bigger than you would like b/c you need to store both >the compression function and the "remainder" of bytes that don't >fit in [0] > Does the handling of Post-Handshake authentication pose a similar issue? That is the need to keep the hash context of the handshake and then append additional data to generate or check the CertificateVerify message? 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
On 18/02/2017 16:26, Viktor Dukhovni wrote: > On Sat, Feb 18, 2017 at 02:31:19AM +0000, 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
On 18/02/2017 10:01, Martin Thomson wrote: > On 18 February 2017 at 13:31, Dr Stephen Henson > <li...@drh-consultancy.co.uk> 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
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
[TLS] Questions on certificate_extensions...
A couple of questions on the format and handling of certificate_extensions. What format is the data that appears in certificate_extension_values? I'd say that it should be in the same format as the content octets of the extnValue field of Extension (from RFC5280 et al). So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF OBJECT IDENTIFIER for Extended Key Usage. As regards the matching rules. How do these apply when a particular extension is absent from the certificate? For example an absent Key Usage is often taken to mean no Key Usage restrictions apply. If Key Usage is present in certificate_extensions does it *require* that the Key Usage extension is explicitly present in the certificate? 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
