Re: [TLS] RSA-PSS in TLS 1.3

Hanno Böck wrote: > m...@sap.com (Martin Rex) wrote: >> >> The *huge* advantage of PKCS#1 v1.5 signatures over RSA-PSS and ECDSA >> signatures is that one can clearly distinguish "wrong public key" >> from "signature does not fit plaintext" error

Re: [TLS] RSA-PSS in TLS 1.3

Hanno Böck wrote: > Joseph Salowey wrote: >> >> 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

Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

Salz, Rich wrote: > Absolute lifetimes seem more robust; e.g., if you find one lying around, > you don't have enough context to know if it's still good or not. > > We went from relative to absolute times in ACME for this reason. What should be memorized/stored is absolute time-of-creation. How

Re: [TLS] 0.5 RTT

Watson Ladd wrote: > > But will they call tls_send_data_replayable? The proper name would be tls_send_data_replayable_and_NO_forward_secrecy. -Martin ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] 0.5 RTT

Karthikeyan Bhargavan wrote: > > Yes Hugo, you?re right that when there is no client auth, > the situation is less problematic. I'm not so sure. There might be the desire of the server to keep some data confidential, and your argument is that if the data wasn't confidential to begin with, the

Re: [TLS] Fixing TLS

Ilari Liusvaara wrote: > > Peter Gutmann wrote: > >> Salz, Rich writes: >> TLS needs an LTS version that you can just push out and leave to its own devices >>> >>>So don't you have that with TLS 1.1 and appropriate cipher and option >>>choices? >> >> Based on the

Re: [TLS] Fixing TLS

Ilari Liusvaara wrote: > Martin Rex wrote: >> Ilari Liusvaara wrote: > >>> Then there's also similar problems with RSA. And then RSA PKCS #1 >>> v1.5 encryption is on just about every "do not use!" list. Get it >>> wrong (good luck getting it right

Re: [TLS] Fixing TLS

Salz, Rich wrote: > >> TLS needs an LTS version that you can just push out and leave to its own >> devices > > So don't you have that with TLS 1.1 and appropriate cipher and option choices? Actually, you already have that with TLSv1.0 plus the known mitigations. The only cryptographical

Re: [TLS] TLS Record Size Limitation

Software Engineer 979 wrote: > > I'm currently developing an data transfer application using OpenSSL. The > application is required to securely transfer large amounts of data over a > low latency/high bandwidth network. The data being transferred lives in a > 3rd part application that uses 1 MB

Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

Jacob Appelbaum wrote: > On 12/2/15, Martin Rex <m...@sap.com> wrote: >> >> So your client will have to know a-priori, out-of-band or be configured >> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello >> with cleartext SNI. > > I th

Re: [TLS] PR#345: IANA Considerations

Eric Rescorla wrote: > > There are presently four categories of cipher suites vis-a-vis TLS 1.3. > > 1. MUST or SHOULD cipher suites. > 2. Standards track cipher suites (or ones we are making ST, like > the ECC ones). > 3. Non standards track cipher suites > 4. Cipher suites you can't use at

Re: [TLS] Record header size?

Yoav Nir wrote: >> Peter Gutmann wrote: >> >> Eric Rescorla writes: >>> >>> The concern here is backward compatibility with inspection middleboxes which >>> expect the length field to be in a particular place. >> >> Given that the rest of TLS 1.3 is

Re: [TLS] Application data during renegotiation handshake

Matt Caswell wrote: > > > On 12/11/15 08:23, Nikos Mavrogiannopoulos wrote: > > On Wed, 2015-11-11 at 18:39 +, Mike Bishop wrote: > > > >> I know that BoringSSL explicitly requires that application data flow > >> be stopped during renegotiation. If the HTTP working group adopts > >> this

Re: [TLS] Controlling use of SHA-1

Viktor Dukhovni wrote: > On Thu, Oct 22, 2015 at 06:40:25PM +, Salz, Rich wrote: >>> >>> Most applications want a simple API that hides all the complexities of >>> TLS. If OpenSSL had done that, then it would be easy to see how enabling >>> 1.2 won't cause problems for those apps which said

Re: [TLS] Controlling use of SHA-1

Martin Thomson wrote: > On 21 October 2015 at 12:56, Viktor Dukhovni wrote: >> Each peer MUST try to send a chain that matches an advertised >> signature algorithm if it has a choice of chains, but otherwise >> MUST send whatever it has. > > Do, or do not. There is no

Re: [TLS] Allow NamedGroups from the server?

Andrei Popov wrote: > > Then my argument would be: why send extra bytes in each ServerHello > when TLS client auth is not used most of the time? In this case, > CertificateRequest seems to be a better place. I'm perfectly OK with the server _not_ sending/including a TLS extension "Supported

Re: [TLS] Allow NamedGroups from the server?

Eric Rescorla wrote: > Dave Garrett wrote: > >> On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote: >>> https://github.com/tlswg/tls13-spec/issues/292 >>> >>> Presently, RFC 4492 only specifies the EC points it can support in >>> ServerHello, but does not let

Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Is the particular interop problem that you want to address caused by a necessity to really process application data and handshake data with arbitrary interleave, or is it rather a problem of getting back into half-duplex operation, i.e. a client being able to continue receiving application data

Re: [TLS] TLS 1.3 - Support for compression to be removed

Watson Ladd wrote: > > Why is it important that clients be permitted to signal support for > compression and TLS 1.3 conditionally? Remember, we also want to phase > out the use of compression in TLS 1.2. compression in TLS is *NOT* generally bad, and not generally a problem. It may be a

Re: [TLS] TLS 1.3 - Support for compression to be removed

Eric Rescorla wrote: > Martin Rex <m...@sap.com> wrote: >> Eric Rescorla wrote: >>> >>> That is what the document says: >>> "Versions of TLS before 1.3 supported compression and the list of >>> compression methods was supplied in this field.

Re: [TLS] TLS 1.3 - Support for compression to be removed

Eric Rescorla wrote: > On Fri, Oct 2, 2015 at 8:24 AM, Salz, Rich wrote: >> >>> 1) We know CRIME threat, but it can not be risk for everyone. >>> e.g., CVSS v2 Base Score: 2.6 (LOW) >> >> CVSS isn't always appropriate; CVSS2 called Heartbleed a 5; CVS v3 called >> it 7.5 >> >>>

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Salz, Rich wrote: > > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started > a proposal that makes SNI-encryption something that can be deployed and > tested on the Internet in TLS 1.3. So we'll see if it gets used and works. > The earlier slides notwithstanding, it's

Re: [TLS] Commentary on the client authentication presentation slides

Andrei Popov wrote: Hi Ilari, What sort of usecase you have in mind for this? This is to support a fairly common website design where the landing page does not require client auth, but subsequent request to a protected resource triggers client authentication within an existing TLS

<    1   2