Re: [TLS] ML-KEM key agreement for TLS 1.3

[Andrey Jivsov]

>
> I would treat non-hybrid drafts in IETF the same way
> as "export" options in code: they're security risks. I would encourage
> explicit withdrawal of any such drafts.


Does this point apply in your opinion to hash-based signatures?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3

[Andrey Jivsov]

This is similar to the case when a server is unable to use its RSA key to
sign with PSS passing (my slides for TLS WG in 2015
https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf , presented
by Eric), but instead this is about client keys/signatures.

I don't have a stake in this currently, but I understand the problem.

In both cases the only current solution is to not negotiate TLS 1.3.


On Tue, Oct 24, 2023 at 5:48 PM Andrei Popov  wrote:

> Hi TLS,
>
>
>
> We would like to re-introduce
> https://datatracker.ietf.org/doc/draft-davidben-tls13-pkcs1/
>
> (it’s intended for the TLS WG and the Standards track, despite what the
> document says at the top; we’ll fix it as soon as the submission tool
> reopens).
>
>
>
> In the course of TLS 1.3 deployment, it became apparent that a lot of
> hardware cryptographic devices used to protect TLS client certificate
> private keys cannot produce RSA-PSS signatures compatible with TLS.
>
> This draft would allow RSA-PKCS signatures in the client CertificateVerify
> messages (and not in any other contexts), as a way to unblock TLS 1.3
> deployments.
>
> This is an unfortunate situation, and work is being done with hardware
> vendors to reduce the likelihood of similar issues in the future, but
> existing devices tend to stay around for years.
>
>
>
> Comments/suggestions are welcome,
>
>
>
> Cheers,
>
>
>
> Andrei
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Point Compression

[Andrey Jivsov]

Looking closer, all what we discuss here is related to ECDH, so the sign of
a point is not important for the result.

In this case the compression can be a simple truncation to , e.g.
without the need to do tricks with the private key to make this an
unambiguous representation of a point. This simple truncation works with
existing software. I think that TLS should adopt the  format (without 02
or 03 prefix).

Note that this truncation extends to the SEC1 compressed format: in this
case we just drop the first byte.

This truncation is highest-performance option and it's simplest too.

On Tue, Oct 26, 2021 at 12:58 AM John Mattsson 
wrote:

> There are several active documents also defining compact representation.
>
>
>
> After the discussion regarding HPKE there was a suggestion EDHOC should
> define a compract format that could be reused by other protocols. That was
> done in an Appendix.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-lake-edhoc-12#page-67
>
>
>
> Also as an outcome of the HPKE discussions Dan Harkins has written on
> compact representation for HPKE submitted to CFRG. This also defines a a
> general format than can be reused by other protocols.
>
> https://datatracker.ietf.org/doc/draft-harkins-cfrg-dnhpke/
>
>
>
> > the support for 'regular' (SEC1) compressed curves is more widespread.
>
>
>
> What is support in this case? An implementation can just use one of the
> values "02" and "03" or flip a coin. If you have support of 'regular'
> (SEC1) compressed curves, then compact representation is trivial.
>
>
>
> Cheers,
>
> John
>
>
>
> *From: *TLS  on behalf of Andrey Jivsov <
> cry...@brainhub.org>
> *Date: *Tuesday, 26 October 2021 at 07:15
> *To: *Carl Mehner 
> *Cc: *IETF TLS 
> *Subject: *Re: [TLS] Point Compression
>
> Do we have evidence that "02 " or "03 " is more widespread than 
> for NIST curves? I haven't seen "02 " or "03 " in deployed products
> in TLS / X.509 at all. So, I feel that for TLS space the slate is clean
> regarding compression. X25519 uses one coordinate, which is simiiar to
> doing  for NIST curves...
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Point Compression

[Andrey Jivsov]

I propose a method to compress NIST curves as defined in
https://tools.ietf.org/id/draft-jivsov-ecc-compact-05.html

Its main benefit is that the compressed point fits into field size / group
order size. There is no additional byte needed.

This encoding is enabled by by modifying key generation. If key generation
code can be changed, the adjustment is one bignum subtraction. If key
generation is a black box, e.g. as if it is done by an HSM, we generate
another key pair until conditions are met.

On average, adjustment is needed every second key generation.

No adjustment is needed for ECDH.

The method is solely based on published books and research papers from the
past century.

I hope this helps.

On Fri, Jul 30, 2021 at 9:48 AM Carl Mehner  wrote:

> As requested during ekr's presentation
> , I will volunteer to write up a
> draft for defining new "supported groups" for compressed NIST curves. I
> didn't see/hear any objections during the tls-wg meeting, but thought
> I should probably confirm on the list before I got too far along in writing
> it...
>
> -carl
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] DH security issue in TLS

[Andrey Jivsov]

https://tools.ietf.org/html/rfc7919#section-5.1 prohibits x=(p-1)/2 because
this results in a peer's public key g^x= 1.

Allowing this makes some man-in-the middle attacks on TLS easier, because
the attacker can predict the value of the ephemeral secret key on another
leg of the connection.

On Tue, Dec 3, 2019 at 3:03 PM Scott Fluhrer (sfluhrer) 
wrote:

> See SRF
>
>
>
> *From:* TLS  *On Behalf Of * Pascal Urien
> *Sent:* Tuesday, December 03, 2019 5:16 PM
> *To:* tls@ietf.org
> *Subject:* [TLS] DH security issue in TLS
>
>
>
> I wonder if g**x , with x =(1-p)/2 is checked in current TLS 1.2
> implementation ?
>
> In RFC https://tools.ietf.org/html/rfc7919
> "Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for Transport
> Layer Security (TLS)"
>
> "Traditional finite field Diffie-Hellman has each peer choose their secret
> exponent from the range [2, p-2].
> Using exponentiation by squaring, this means each peer must do roughly
> 2*log_2(p) multiplications,
> twice (once for the generator and once for the peer's public key)."
>
> Not True !!!
> Even for p= safe prime (i.e.. Sophie Germain prime, p=2*q+1, with p & q
> prime number) secret exponent x= (p-1)/2 is a security issue since :
>
> g**xy = 1   with y an even integer
> g**xy = g**x   for y an odd integer
>
>
>
> SRF: actually, g**xy  = 1 in both cases, as g**x = 1 (for the g, p values
> specified in RFC7919); this is easily seen as all listed p values are safe
> primes, and in all cases, g=2 and p=7 mod 8.
>
>
>
> In any case, why would that be a security issue?  If both sides are honest
> (and select their x, y values honestly), the probability of one of them
> selecting (p-1)/2 as their private value is negligible (even if our
> selection logic allowed that as a possible value – it generally doesn’t).
> If we have two honest parties with an adversary replacing one of the side’s
> key share with g**(p-1)/2, well, the protocol transmits signatures of the
> transcript, and so that’ll be detected. If you have an honest side
> negotiating with a dishonest one, well, the dishonest one could select
> (p-1)/2 as its private value – however, they could also run the protocol
> honestly (and learn the shared secret and the symmetric keys, which are
> usually the target), and there’s nothing the protocol can do about that.
>
>
>
> Now, if an honest party reused their private values for multiple
> exchanges, a similar observation would allow an adversary to obtain a
> single bit of the private value.  He would do that by performing an
> exchange with the honest party mostly honestly, selecting a value x as his
> private value, but instead of transmitting g**x as his key share, he would
> transmit -g**x.  Then, the shared value that the honest party would derive
> is:
>
>
>
>   g**xy  with y an even integer
>
>   -g**xy  with y an odd integer
>
>
>
> The adversary can compute both these values, and determine which is being
> used later in the protocol.
>
>
>
> So, the adversary can learn a single bit of the private value (which
> doesn’t translate to him learning any bit of the shared secret, much less
> the symmetric keys) – however, he cannot leverage this to learn anything
> else of the private key.  I do not believe that a single bit is worth
> worrying about.  And, again, if we generate a fresh DH private value for
> every exchange (which we encourage people to do for PFS), even that single
> bit doesn’t apply to any other exchange.
>
>
>
>
>
> If p is not a safe prime (like in RFC 5114) other issues occur
>
>
>
>
>
> Pascal
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Drafts for batch signing and PKCS#1 v1.5

[Andrey Jivsov]

Regarding PKCS 1.5 in TLS 1.3, please also see slide 4 for a year 2015
version of the same motivation
https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf .

On 7/29/19 5:15 PM, David Benjamin wrote:
> Hi all,
> 
> I’ve just uploaded a pair of drafts relating to signatures in TLS 1.3.
> https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00
> https://tools.ietf.org/html/draft-davidben-tls-batch-signing-00
> 
> The first introduces optional legacy codepoints for PKCS#1 v1.5
> signatures with client certificates. This is unfortunate, but I think we
> should do it. On the Chrome side, we’ve encountered some headaches with
> the TLS 1.3 PSS requirement which are unique to client certificates. The
> document describes the motivations in detail.
> 
> The second describes a batch signing mechanism for TLS using Merkle
> trees. It allows TLS clients and servers to better handle signing load.
> I think it could be beneficial for a number of DoS and remote key scenarios.
> 
> Thoughts?
> 
> David
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

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

Re: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

[Andrey Jivsov]

Why isn't the

"The server indicates
the choice of group to the client by sending the group's parameters
as usual in the ServerKeyExchange"
https://tools.ietf.org/html/rfc7919#section-4

an evidence that the server supports RFC 7919?

On 2/20/19 10:29 AM, David Benjamin wrote:
> (We haven't actually implemented RFC 7919 and have no plans to, so I'm
> just going by the document.)
> 
> RFC 7919 doesn't say anything, so I think the only reasonable
> interpretation is to continue with the legacy option for TLS 1.2 and
> below. It's also the only interoperable option given how the document is
> set up. RFC 7919 repurposed the existing DHE scheme with no directly
> visible server differences, so the client cannot tell if it is talking
> to a post-7919 server, or a pre-7919 server that happened to use a
> well-known parameter. That means 7919 cannot change how DHE works. (This
> isn't the only consequence of that decision.
> See https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo.
> DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.)
> 
> Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more
> sound method and does:
> https://tools.ietf.org/html/rfc8446#section-7.4.1
> 
> On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov  <mailto:cry...@brainhub.org>> wrote:
> 
> Greetings.
> 
> it's unclear to me how is the shared secret g^xy calculated for groups
> in https://tools.ietf.org/html/rfc7919 .
> 
> If you recall, the TLS 1.1 uses this method the
> https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some
> interoperability problems that are hard to fix.
> 
> The RFC 7919 doesn't specify what to do here.
> 
> So, the question is, assuming that ffdhe2048 is negotiated,
> 
> - is g^xy padded to 256 bytes (more sound method) or
> - the leading zero bytes of g^xy must be stripped (legacy method, used
> for historic reasons)?
> 
> Thank you.
> 
> ___
> TLS mailing list
> TLS@ietf.org <mailto:TLS@ietf.org>
> https://www.ietf.org/mailman/listinfo/tls
> 

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

[TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

[Andrey Jivsov]

Greetings.

it's unclear to me how is the shared secret g^xy calculated for groups
in https://tools.ietf.org/html/rfc7919 .

If you recall, the TLS 1.1 uses this method the
https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some
interoperability problems that are hard to fix.

The RFC 7919 doesn't specify what to do here.

So, the question is, assuming that ffdhe2048 is negotiated,

- is g^xy padded to 256 bytes (more sound method) or
- the leading zero bytes of g^xy must be stripped (legacy method, used
for historic reasons)?

Thank you.

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 10:13 PM, Martin Thomson wrote:
> On Wed, May 30, 2018 at 2:53 PM Andrey Jivsov  wrote:
>> The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
>> support TLS 1.3 is new.
> No, I'm certain we had that discussion too.
>
>> I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
>> will take place?
> When people deploy TLS 1.3.  Which is happening already.  You can avoid the
> need as a server because a client willing to do TLS 1.2 will probably offer
> RSASSA PKCS#1 v1.5 and you can rely on that being there.  But yeah, clients
> are going to have to suck it up.  Here's the text, which I think is pretty
> clear:
> "
> Implementations that advertise support for RSASSA-PSS (which is mandatory
> in TLS 1.3), MUST be prepared to accept a signature using that scheme even
> when TLS 1.2 is negotiated. "

Correct. That's the single paragraph that I think should not be there.

As I asked in the previous message, what is a scenario when this
paragraph helps? When will we see a fallback to TLS 1.2 AND upgrade of
legacy PKCS#1.5 to PSS (within TLS 1.2)? Why such a server could not
accept TLS 1.3 and use PSS there?

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 06:17 PM, Martin Thomson wrote:
> On Wed, May 30, 2018 at 7:20 AM Andrey Jivsov  wrote:
>> The issue here is that some hardware devices don't implement RSA CRT
>> method with PSS, because they hard-wide RSA, legacy padding, and CRT
>> method in one operation. RSA PSS can still be done, but only via a
>> general modexp operation, which will be ~2x shower. Therefore, in these
>> scenarios PSS incurs 2x performance penalty.
> 
> I'm fairly certain that we've had this discussion before.  What is new?
> 

The quoted text quoted is old. The need to upgrade TLS 1.2 code if I
support TLS 1.3 is new.

I am curious about the scenarios when is this upgrade of TLS 1.2 to PSS
will take place?

- This upgrade of TLS 1.2 can only be done by servers that support TLS 1.3.
- TLS 1.2 clients won't advertise TLS 1.3 Signature Algorithm IDs; only
TLS 1.3 clients will have e.g. rsa_pss_rsae_sha256 and others in
signature_algorithms.

Therefore, TLS 1.3 should get negotiated between these peers.

The relevant paragraph from the TLS 1.3 draft seems to add uncertainty
in unexplained cases when TLS 1.3 server decides to drop the negotiated
version to TLS 1.2. What problem does this paragraph try to solve?

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

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 01:58 PM, David Benjamin wrote:
> On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov  <mailto:cry...@brainhub.org>> wrote:
> 
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and this is fine. You are able to verify RSA-PSS signatures from
> > the server at TLS 1.3.
> >
> > At the same time, you still talk to some TLS 1.2 servers, so you
> may get
> > a response from them. As TLS 1.2 and TLS 1.3 use the same signature
> > algorithms negotiation, that same ClientHello obligates your client
> > (newly updated to support TLS 1.3) to also verify RSA-PSS signatures
> > from TLS 1.2. But this causes troubles somehow.
> >
> > I'm confused how a client would have an RSA-PSS function available at
> > one version, but not the other. Or am I misunderstanding your
> situation?
> 
> There is a need to upgrade TLS 1.2 stack, just because one can now
> negotiate TLS 1.3.
> 
> 
> I think this came up on the list earlier which way to go here, and folks
> seemed to generally prefer this one. In our implementation, we unified
> the TLS 1.2 and TLS 1.3 signature logic which made things simpler
> overall. I think this was true for most folks.
>  
> 
> Does this "upgrade" to TLS 1.2 extends to client authentication? Then
> this adds more work.
> 
> 
> There can be a performance penalty with RSA-PSS v.s. RSA legacy and more
> issues when private keys are used in client authentication (because e.g.
> they are HSM keys).
> 
> 
> The client authentication scenario seems unrelated to me. In both TLS
> 1.2 and TLS 1.3, there is no relation between the client's advertised
> signature algorithm list (which is the algorithms it will *accept* from
> the server) and the client's signing preferences (which control the
> CertificateVerify it will *send*). The latter is never even sent over
> the wire.
> 
> As a client, you get to choose which signature algorithm you use.
> Offering RSA-PSS to the server for its TLS 1.2 ServerKeyExchange does
> not obligate you to select it in your TLS 1.2 CertificateVerify. You
> select out of what the server offered in CertificateRequest. This code
> point allocation means the server *may* offer RSA-PSS and you *may*
> select it if offered. But if that is difficult for whatever reason, you
> also can still select PKCS#1 if the server offers it. (Of course, the
> server may offer you only things you can't handle, but that's not a new
> concern.)

OK. We don't know, though, what will happen in practice with TLS 1.2
CertificateRequest if the server upgraded TLS 1.2 ServerKeyExchange.
Will it be more likely that the choices in CertificateRequest will be
narrower?

> 
> Chrome does just that. Our verify preferences include RSA-PSS, but our
> signing preferences when configured for client certificates are
> separate, precisely because of issues with smartcards and the like.
> 
> As for the performance penalty, I think it was clearly the WG's
> consensus that the benefits of migrating to PSS outweighed the entropy
> draw and hash operations that PSS takes.

The issue here is that some hardware devices don't implement RSA CRT
method with PSS, because they hard-wide RSA, legacy padding, and CRT
method in one operation. RSA PSS can still be done, but only via a
general modexp operation, which will be ~2x shower. Therefore, in these
scenarios PSS incurs 2x performance penalty.

( Maybe RSA verification should be done on CPU, but this will require
changes to TLS 1.2 code. )

The limitations are similar to what you wrote about smartcards. There
are some odd hardware limitations. That hardware was just fine years ago
with TLS 1.2.

Higher entropy consumption is negligible here.

>  
> 
> >
> > On Tue, May 29, 2018 at 4:05 PM Andrey Jivsov  <mailto:cry...@brainhub.org>
> > <mailto:cry...@brainhub.org <mailto:cry...@brainhub.org>>> wrote:
> >
> >     On 05/29/2018 12:42 PM, Benjamin Kaduk wrote:
> >     > On Tue, May 29, 2018 at 12:35:20PM -0700, Andrey Jivsov wrote:
> >     >> On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> >     >>> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
> >     >>>> Greetings.
> >     >>>>
> >     >>>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells
> that if
> >     a client
> >     >>>> wants to negotiate TLS 1.3, it must support an upgra

Re: [TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

On 05/29/2018 12:13 PM, Benjamin Kaduk wrote:
> On Tue, May 29, 2018 at 11:57:39AM -0700, Andrey Jivsov wrote:
>> Greetings.
>>
>> TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
>> wants to negotiate TLS 1.3, it must support an upgraded (and
>> incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
>> RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.
>>
>> You might recall that the possibility to negotiate between PSS and
>> RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
>> signatures, was discussed on the mailing list. The WG decision then was
>> to hard-wire PSS in the TLS 1.3 handshake.
>>
>> I don't recall any discussion on going further than this, all the way to
>> changing the 10-year old TLS 1.2.
>>
>> Unfortunately, our products have issues with PSS beyond our control. The
>> only solution left to avoid receiving PSS with TLS 1.2 is to never
>> negotiate TLS 1.3 as a client. Another solution is insecure fallback,
>> but we presently don't do this.
>>
>> Is my reading of the situation correct? Thank you.
> 
> Sounds like it:
> 
>RSASSA-PKCS1-v1_5 algorithms  Indicates a signature algorithm using
>   RSASSA-PKCS1-v1_5 [RFC8017] with the corresponding hash algorithm
>   as defined in [SHS].  These values refer solely to signatures
>   which appear in certificates (see Section 4.4.2.2) and are not
>   defined for use in signed TLS handshake messages, although they
>   MAY appear in "signature_algorithms" and
>   "signature_algorithms_cert" for backward compatibility with TLS
>   1.2,
> 
> -Ben
> 

I was referring to
> 
>-  Implementations that advertise support for RSASSA-PSS (which is
>   mandatory in TLS 1.3), MUST be prepared to accept a signature
>   using that scheme even when TLS 1.2 is negotiated.  In TLS 1.2,
>   RSASSA-PSS is used with RSA cipher suites.

I am OK with what you quoted. What I just quoted represents a
significant change in behavior in TLS 1.2 and there is no way to opt out
of this change to TLS 1.2.

I will add that I've seen this behavior by servers already, even when
client doesn't advertise TLS 1.3. Just the fact of including some 08 xx
IDs in signature_algorithms in ClientHello, without protocol_version
extension, gets the TLS 1.2 upgraded to RSA-PSS.

IMO this paragraph should be removed. Those that want PSS in the
handshake should negotiate TLS 1.3. Preservation of current behavior of
TLS 1.2 is important, at least as an option.

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

[TLS] Is it possible for a client to offer TLS 1.3, but not be forced to support RSA PSS in TLS 1.2?

[Andrey Jivsov]

Greetings.

TLS 1.3 draft in sec 4.2.3.  Signature Algorithms tells that if a client
wants to negotiate TLS 1.3, it must support an upgraded (and
incompatible) version of TLS 1.2, the one that changes RFC 5246 to allow
RSA-PSS in sec. 7.4.1.4.1. Signature Algorithms.

You might recall that the possibility to negotiate between PSS and
RSASSA-PKCS1-v1_5 in TLS 1.3 handshake, just as it is allowed for X.509
signatures, was discussed on the mailing list. The WG decision then was
to hard-wire PSS in the TLS 1.3 handshake.

I don't recall any discussion on going further than this, all the way to
changing the 10-year old TLS 1.2.

Unfortunately, our products have issues with PSS beyond our control. The
only solution left to avoid receiving PSS with TLS 1.2 is to never
negotiate TLS 1.3 as a client. Another solution is insecure fallback,
but we presently don't do this.

Is my reading of the situation correct? Thank you.
 

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

Re: [TLS] Improved nonce generation method for TLS 1.3

[Andrey Jivsov]

Regarding [2], we should be counting the functionality for serialization
and the increment of record number needed by the current nonce method.

Serialization would need two bswaps for little-endian platforms and an
increment. (We need to bring the integer into host format first, thus
the roundtrip with swaps.)

These are the 3 instructions that I counted: two bswaps, one increment.
That's all that my method needs.

If we assume that the layers are mixed together, there may be some reuse.

If we consider a stronger separation, where the encryption layer is as
independent as possible, it will have to do what the current TLS 1.3
prescribes independently.

I am not saying that performance savings due to this proposal are
significant. However, some may do encryption in hardware, while the
nonce will probably always be in software. My main point here is
simplicity. It seems easier to me to increment 12 bytes (suppressing the
carry) in-place.

On 06/02/2017 04:20 PM, Adam Langley wrote:
> On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <cry...@brainhub.org
> <mailto:cry...@brainhub.org>> wrote:
> 
> The benefits are that the encryption layer doesn't need to deal with a
> record number or its serialization, or the mask. The state is minimal.
> The nonce update code is faster and smaller (e.g. 3 instructions on
> x86_64).
> 
> I would like to thank earlier reviewers. As part of these reviews
> RFC7905 was brought up. I appreciate the desire not to update the
> RFC7905, but this should not interfere with the WGLC, and it's a fairly
> new stream cipher anyway.
> 
> 
> If the encryption layer implements the standard interface[1] then it
> doesn't care about any of this anyway. Also, I'm not sure that it is any
> faster (the current scheme can be done in three x86-64 instructions
> too[2]), but any difference would be immeasurably tiny compared to the
> work of the AEAD itself.
> 
> The overriding interest here is to avoid having yet another nonce
> format. RFC 7905 diverged from TLS 1.2 with the intent that it would
> align with TLS 1.3. There would have to be a significant reason to add
> more complexity.
> 
> [1] https://tools.ietf.org/html/rfc5116#section-2.1
> [2] context struct addr in rax, seq number in rcx: leaq
> maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi)
> 
> 
> Cheers
> 
> AGL
> 
> -- 
> Adam Langley a...@imperialviolet.org <mailto:a...@imperialviolet.org>
> https://www.imperialviolet.org

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

[TLS] Improved nonce generation method for TLS 1.3

[Andrey Jivsov]

Greetings.

I would like to suggest a small tweak to the nonce generation method in
TLS 1.3.

The motivation for this is stronger separation between the encryption
layer and the TLS layer. An alignment with FIPS 140 guidance is another
motivation, which tells that the IV management shall be internal (in
encryption direction).

I realize that what I propose is a small tweak, and consequently, it
provides small benefits. One can take any side here. My view is that we
should try to clean things up, when possible.

Instead of requiring the understanding of the record numbers, the
encryption layer simply increments the initial nonce, which is a 12-byte
quantity for AES-GCM. The TLS layer passes in client_write_iv or
server_write_iv, along with the key, once per session, and the
encryption layer does ++ on nonce for each record from that point.

The method can be described as a counter mode with a random start.

There is one caveat. In order to maintain protocol version independence
we want to inhibit carry into the higher bytes (4 high bytes for
AES-GCM). This is behavior is standardized by
https://tools.ietf.org/html/rfc5116 and applies to TLS 1.2.

The benefits are that the encryption layer doesn't need to deal with a
record number or its serialization, or the mask. The state is minimal.
The nonce update code is faster and smaller (e.g. 3 instructions on x86_64).

I would like to thank earlier reviewers. As part of these reviews
RFC7905 was brought up. I appreciate the desire not to update the
RFC7905, but this should not interfere with the WGLC, and it's a fairly
new stream cipher anyway.

Details are in https://github.com/tlswg/tls13-spec/pull/1027

Thank you.

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

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

[Andrey Jivsov]

On 03/02/2017 05:54 PM, Hal Murray wrote:
> 
> cry...@brainhub.org said:
>> I also think that counting in blocks is cleaner. Counting in bytes is a
>> close alternative. 
> 
> Does counting bytes work?  If the real limit is blocks, I think you will have 
> to round up the byte count when you send a partial block.
> 
> If re-keying too often isn't too expensive, you could get a safe answer by 
> counting bytes and assuming that every byte went in a separate block.
> 
> You might want to round down many more orders of magnitude so the re-key code 
> gets exercised often enough.  Or maybe provide a back door to set the limit 
> so that path can be tested with reasonable resources.
> 

I like the idea of setting the rekey limits, so that the code can be
tested. There is no 3DES in TLS 1.3.


You refer to some under-counting.

The worst case is mod 16 = 1 byte sized TLS records, in which case the
"tails" will only be counted as 1 block per 16 TLS records v.s. desired
16. We are undercounting less than one 16-byte block per record.

One can count in record_size_in_bytes + 16 as one solution (overcount).

However, is it true that 1-byte terminal blocks must be counted as full
16-byte blocks? 1-byte blocks don't seem to directly apply to the proofs
with distinguishing game. With 1-byte plaintext / ciphertext we are not
making statements about two values from the 1^128 members space. Rather,
we are discussing two values from the tiny 256 members space. Also, a
truncated AES-GCM encryption behaves as PRF and not PRP.

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

Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 07/06/2016 10:23 AM, Joseph Salowey wrote:
> I don't think we ever call consensus on this topic.  It looks like there
> is rough consensus to move forward with RSA-PSS as the MUST implement
> algorithm for certificate verify in TLS 1.3 and not allow PKCS-1.5.  
> During the discussion it also seemed that it is realistic that we may
> want to add additional types in the future.  We may want better
> separation of signature types of certificates and certificate verify.  
> 
> Cheers,
> 
> J

Was it really the consensus that the group didn't want to allow PKCS-1.5
negotiated for handshake signatures (for certificate verifies)?

TLS 1.3 currently allows this agility for other signatures: the
signatures in X.509 certificates.

Nobody has objections to a MUST implement and MUST prefer RSA-PSS in TLS
1.3.


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

Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 02/29/2016 02:36 PM, Hanno Böck wrote:

We have an RFC for PSS since 2003.
We had several attacks showing the weakness of PKCS #1 1.5.


In the face of such danger, what's your opinion on PKCS #1.5 signatures 
being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs 
in the latest https://tools.ietf.org/html/draft-ietf-tls-tls13-11.


Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 
1.3 more secure, but code simpler and footprint smaller. Besides, it's 
reasonable: TLS 1.2 already allows PSS in X.509 certs.


You are arguing for the benefit of suddenly mandating a steel door on a 
grass hut. Joseph Salowey's proposal gives an option for the door, 
consistent with how TLS 1.2 does this for X.509 certs.


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

Re: [TLS] RSA-PSS in TLS 1.3

[Andrey Jivsov]

On 02/29/2016 09:32 AM, Joseph Salowey wrote:
> We seem to have good consensus on moving to RSA-PSS and away from
> PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take some
> hardware implementations some time to move to RSA-PSS.  After an off
> list discussion with a few folks here is a proposal for moving forward.
>
> We make RSA-PSS mandatory to implement (MUST implement instead of MUST
> offer).   Clients can advertise support for PKCS-1.5 for backwards
> compatibility in the transition period.
> Please respond on the list on whether you think this is a reasonable way
> forward or not.

I think that supporting PKCS1.5 fallback is the right thing to do for 
wider adoption of TLS 1.3, as specified above.


PKCS #1.5 is allowed by 
https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in 
X.509 certificates. X.509 certificate chain is a part of TLS handshake. 
The above proposal is about not restricting one type of signature, the 
end-entity signature, to PSS. This applies to client authentication, 
server authentication, or both.


Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we 
have to deal with already deployed hardware. Had vendors and customers 
knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up 
with more PSS-friendly Internet. Even now PKCS#1.5 is allowed by FIPS 
140, Common Criteria, and in CA certificates in TLS 1.3, and earlier TLS.


The WG can chose to remove PSS from one type of signature in TLS1.3. 
This will result in affected implementations capping negotiation at TLS 
1.2. There is no other fix in some cases.


For more details: 
https://www.ietf.org/mail-archive/web/tls/current/msg19096.html


(I posted earlier, but don't see the message. Sending this one more 
time, slightly edited)


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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov]

On 01/25/2016 03:11 PM, Russ Housley wrote:

On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:


On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:

On 01/22/2016 01:14 PM, Hubert Kario wrote:

On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:

On 01/22/2016 03:14 AM, Hubert Kario wrote:

The only solution that's available at this point is conditioning
TLS
1.3 support on appropriate hardware. For this reason TLS 1.3 it
probably won't be enabled by default in the product I work on. I
would prefer for TLS 1.3 to be enabled by default and write the
code
to decide whether it does PSS or falls back to RSA PKCS1 1.5.

Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not
cutting it off now would be negligent.

You mean for HS only, while leaving it for X.509 certs?

If we don't do it for HS in TLS first, we'll never get rid of it in
X.509 certs.

We need to start somewhere, and it's more reasonable to expect that
hardware with support for new protocols will get updated for RSA-PSS
handling than that libraries and hardware will suddenly start
implementing it in droves just in anticipation of the time when CAs
_maybe_ will start issuing certificates signed with RSA-PSS.

Isn't it more a matter of TLS being a consumer of external PKIX
infrastructure, the web PKI, etc.?  They are out of the reach of the
IETF TLS working group; any requirements we attempted to impose would
be unenforceable, even if there was an Internet Police (which there
is not).

TLS will happily use PKCS#1 v1.5 signed X.509 certificates, so how
exactly is creating a side effect of increasing the deployment rate of
RSA-PSS _in TLS implementations_ an "overreach"?!

I have been a supporter of PSS for a very long time -- see RFC 4055.

We have many algorithm transition issues, but this is one place where we have 
seen very little progress.  I would like to see support for PSS in the 
protocol, even if we need to support PKCS v1.5 for certificate signatures for a 
long time.


Is there evidence that hard-wiring {PSS} in HS and {PSS, PKCS#1 1.5} 
with X.509 certs will lead to better PSS adoption than if {PSS, PKCS#1 
1.5} were available in both HS and X.509 certs?


This should be balanced against the reality that PSS in HS with TLS 1.3 
guarantees lower TLS 1.3 adoption as I wrote above. PSS-only in TLS 1.3 
HS may make code more complex as well.


I am trying to imagine a logic that a TLS 1.3 client supporting 
smartcard client authentiation would need to implement, assuming 
mandatory PSS signing in HS, e.g. a case of Firefox + PKCS#11 interface 
with a smartcard.


First, the code should query (attached? logged-in?) smartcard(s) to 
determine if the key(s) on the smartcard that might be used for client 
authentication can do PSS signing. PKCS#11 interface lists the PSS 
capability as CKM_SHA256_RSA_PKCS_PSS mechanism. If no such PSS+hash 
mechanism is available, the code needs to tag the keys(s) as TLS 
1.2-only. When the client connects to a TLS 1.3 server and the server 
requests client authentication with the non-PSS key, I think this will 
require protocol dance down to TLS 1.2 (insecure TLS fallback). 
Alternatively, the client will need to start from TLS 1.2 when it 
detected such a smartcard, for any server.


The underlying reasons why CAs can't sign with PSS v.s. TLS server or 
client are probably overlapping in many cases: FIPS 140, HSM, hardware. 
The all-or-nothing approach to PSS sin HS eems inconsistent with 
traditional feature negotiation in TLS HS.



Russ


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


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

Re: [TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov]

On 01/22/2016 03:14 AM, Hubert Kario wrote:

On Thursday 21 January 2016 18:25:00 Andrey Jivsov wrote:

Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the
following language in sec 4.8.1


 In RSA signing, the opaque vector contains the signature
 generated
 using the RSASSA-PSS signature scheme defined in [RFC3447
 <http://tools.ietf.org/html/rfc3447>] with MGF1. The digest
 used in the mask generation function MUST be the same as the
 digest which is being signed (i.e., what appears in
 algorithm.signature).  The length of the salt MUST be equal to
 the
 length of the digest output.  Note that previous versions of TLS
 used
 RSASSA-PKCS1-v1_5, not RSASSA-PSS.


The


struct {

   SignatureAndHashAlgorithm algorithm;
   opaque signature<0..2^16-1>;

} DigitallySigned;


defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec

A.3.1.1:

enum {

rsa(1),
dsa(2),
ecdsa(3),
rsapss(4),
eddsa(5),
(255)

} SignatureAlgorithm;


since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates
only.


Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as
frictionless as possible regarding the upgrade of existing TLS
installations to TLS 1.3. We should expect that all TLS 1.3 servers
and clients will have support for older versions of TLS on the same
node. Ideally, it should be possible to upgrade the software /
firmware to add TLS 1.3 support on existing hardware with minimal
penalty.


The transition to TLS 1.3 is not urgent matter. Making sure that it is
as robust as possible is of higher importance than "making it easy to
implement for existing TLS1.2 implementations".

That's right there in the charter:
https://datatracker.ietf.org/wg/tls/charter/


The issue here is to be able to use existing hardware with TLS 1.3.

The CAs got PKCS#1 1.5 exemption under TLS 1.3. I suppose that the 
reason HS did not get matching capability is it was believed that 
PSS-only would not be a problem. I noted a few problems with PSS in HS.





The current list of FIPS 140 products that support RSA shows twice as
many products that support RSASSA-PKCS1_V1_5 than these that support
RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS
certification with TLS 1.3, factoring client auth and servers.


You also need a FIPS certified implementation of HKDF. So yes, it most
likely will require new certifications.


HKDF is somewhat orthogonal to the this thread.

I was pointing out that there are devices, e.g. FIPS PCI cards or 
smartcard, that "hold" RSA keys. Some of them can only do RSA PKCS#1 1.5 
signing with these keys. These devices work with TLS 1.2 and won't work 
with TLS 1.3. These problems might be fixable if vendors are willing to 
do so, but observe that for FIPS devices this means more costly and 
slower re-certification, not just firmware update.


Regarding HKDF, note that FIPS 140-2 specifically says that it doesn't 
certify TLS, SSH, or protocols in general. It certifies crypto 
primitives. Vendors are free to chose which crypto primitives they 
certify (and this set is noted on the FIPS certificate).


KDFs in TLS are covered by 
http://csrc.nist.gov/groups/STM/cavp/documents/components/askdfvs.pdf. 
TLS 1.2 KDF is noted as "TLS KDF" on 
http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/1401val2014.htm . 
Not many modules claim certification for TLS KDF for current TLS and 
this may continue to be the case for HKDF in TLS.


In our case we do TLS KDF "ourselves" and I think other conceivable 
implementations can do this too, so this is not an issue in this thread.





The only solution that's available at this point is conditioning TLS
1.3 support on appropriate hardware. For this reason TLS 1.3 it
probably won't be enabled by default in the product I work on. I
would prefer for TLS 1.3 to be enabled by default and write the code
to decide whether it does PSS or falls back to RSA PKCS1 1.5.


Yes, it would be nice. But PKCS#1 v1.5 had it long coming. Not cutting
it off now would be negligent.


You mean for HS only, while leaving it for X.509 certs?

More importantly, note that while I understand the intent to increase 
security by mandating PSS in TLS 1.3, in practice it doesn't work.


We/our customers will have to select the highest protocol that works (or 
is reasonably fast). If the spec is written to mean (TLS1.3 && PSS), if 
we can't do PSS, we can't do TLS 1.3. There are other desirable security 
enhancements in TLS 1.3, besides PSS, that would be nice to deploy.


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

[TLS] Case for negotiation of PKCS#1.5 RSASSA-PKCS1-v1_5 in TLS 1.3

[Andrey Jivsov]

Current draft of TLS 1.3 [1] mandates RSA-PSS in TLS handshake by the 
following language in sec 4.8.1



In RSA signing, the opaque vector contains the signature generated
using the RSASSA-PSS signature scheme defined in [RFC3447  
] with MGF1.
The digest used in the mask generation function MUST be the same as
the digest which is being signed (i.e., what appears in
algorithm.signature).  The length of the salt MUST be equal to the
length of the digest output.  Note that previous versions of TLS used
RSASSA-PKCS1-v1_5, not RSASSA-PSS.


The


   struct {
  SignatureAndHashAlgorithm algorithm;
  opaque signature<0..2^16-1>;
   } DigitallySigned;


defines RSA PKCS#1 1.5 and RSA PSS as "rsa" and "rsapss", see sec A.3.1.1:


   enum {
   rsa(1),
   dsa(2),
   ecdsa(3),
   rsapss(4),
   eddsa(5),
   (255)
   } SignatureAlgorithm;


since draft -09 (posted Oct 2015). "rsa" applies to X.509 certificates only.


Many implementers of TLS 1.3 expressed desire for the TLS 1.3 to be as 
frictionless as possible regarding the upgrade of existing TLS 
installations to TLS 1.3. We should expect that all TLS 1.3 servers and 
clients will have support for older versions of TLS on the same node. 
Ideally, it should be possible to upgrade the software / firmware to add 
TLS 1.3 support on existing hardware with minimal penalty.


Unfortunately, the product I work on, which is responsible for ~15% of 
Internet traffic, is not compatible with the "frictionless idea" due to 
the current TLS 1.3 spec [1] mandating PSS in the handshake.


The issue here is that these already sold products use 3d party 
components that can only perform RSA signing with CRT optimization when 
the padding is PKCS1 1.5. In the best case this means ~2x performance 
penalty for TLS 1.3. In the worst case the existing server keys cannot 
do PSS signature if the keys are on FIPS-certified devices.


The same issue applies to client TLS authentication with smartcards. 
Many smartcards cannot do PSS, e.g. [3].


Likewise, it's unclear if PSS is supported by e.g. PKCS#11 libraries of 
HSM vendors, or the HSM hardware.


Other products on the Internet use the same components, so that 15% is a 
minimum I know of.


The current list of FIPS 140 products that support RSA shows twice as 
many products that support RSASSA-PKCS1_V1_5 than these that support 
RSASSA-PSS [4]. There is greater than 50% chance to lose FIPS 
certification with TLS 1.3, factoring client auth and servers.


Can support for PSS be added by 3d party vendors? If the limitation is 
in middleware like PKCS#11 or in firmware/microcode, this is technically 
possible. This does require an update and the brings version dependency. 
Further, if the firmware is FIPS 140-2 certified, this type of upgrade 
will have re-certification cost (more friction). In some cases this is a 
physical limitation. For example, I know from my experience working on 
smartcard decryption a few years back that the chips themselves insist 
on PKCS#1.5 padding for half of the vendors we supported and won't e.g. 
accept raw or OAEP padding with RSA, e.g. [2]. It is apparent from the 
specs that [3] does support PSS while [2] doesn't.


I prepared the slides on this subject for Yokohama [5]. I believe Eric 
Rescorla presented these.


How much do the members of the WG value the idea of lower hurdles to the 
deployment of TLS 1.3? Is there desire to add a PKCS#1 1.5 signature 
fallback, just like there is one already for X.509 certificates in TLS 1.3?


The only solution that's available at this point is conditioning TLS 1.3 
support on appropriate hardware. For this reason TLS 1.3 it probably 
won't be enabled by default in the product I work on. I would prefer for 
TLS 1.3 to be enabled by default and write the code to decide whether it 
does PSS or falls back to RSA PKCS1 1.5.


Thank you.

[1] http://tools.ietf.org/html/draft-ietf-tls-tls13-11.html
[2] 4.4 has no PSS: 
http://jp.atos.net/content/dam/global/we-do/cardos-datenblatt.pdf
[3] 5.0 has PSS: 
https://atos.net/content/dam/global/we-do/cardos-v5-datenblatt.pdf


[4] 2x more legacy than PSS: 
http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html

wget http://csrc.nist.gov/groups/STM/cavp/documents/dss/rsanewval.html
$ grep RSASSA-PSS rsanewval.html | wc -l
593
$ grep RSASSA-PKCS1_V1_5 rsanewval.html | wc -l
2005
$ grep RSASSA rsanewval.html | wc -l
2607

[5] https://www.ietf.org/proceedings/94/slides/slides-94-tls-4.pdf 
https://www.ietf.org/jabber/logs/tls/2015-11-04.html


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