Re: [TLS] Current TLS 1.3 state?

I don't know what the state of the various modelling efforts is, though I imagine this will be a topic at TLS:DIV at the end of the month. We did discuss the various cryptographic changes in -20 (specifically the extra key derive stages and the handshake hash reification) with a number of crypto

Re: [TLS] Current TLS 1.3 state?

We’re hoping that the TLS:DIV workshop later this month will serve to gather some opinions from the academic community on the current spec. https://www.mitls.org/tls:div/ At IEEE S&P (Oakland), there will be at least two papers on analyses of draft 18: - A ProVer

Re: [TLS] draft-thomson-tls-record-limit-00

Hi Thomas, Sorry for taking so long to get back to this. https://github.com/martinthomson/tls-record-limit/pull/1 covers the major changes. I decided to add a section covering the expansion issue so that I could do it justice. I was going to write more, then I realized that the dumb approach is

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

It seems the intention behind short lived certificates is pretty clear: Server operators often want to create short-lived certificates for servers in low- trust zones such as CDNs or remote data centers. But even if this is true it needs to be analyzed why server operators want to do th

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

>Server operators >often want to create short-lived certificates for servers in low- >trust zones such as CDNs or remote data centers. But as currently specified, that low-trust short-lived certificate, if captured, can be used to spoof the operator anywhere else in the world. Yes,

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

I agree, that's why I only see a security gain if the theft of the certificate remains undetected. On 05/04/17 14:35, Salz, Rich wrote: >>Server operators >>often want to create short-lived certificates for servers in low- >>trust zones such as CDNs or remote data centers. > But as cu

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > Hello, > > How is Certificate Compression advantageous over tls cached-info extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi wrote: > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > >> Hello, >> >> How is Certificate Compression advantageous over tls cached-info >> extension? >> Only case I can think of is - when the certificate is being sent for the >> first ti

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

> There is also an alternate world in which the TLS terminators should not have > certificates/keys on them but it is okay to give them delegated credentials. > Here, one benefit is clear: performance. But the attacker capabilities > against which this is supposed to be useful/acceptable remai

Re: [TLS] Certificate compression draft

On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > > > On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria > wrote: > > Hello, > > How is Certificate Comp

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

On 04/05/2017 11:07 AM, Subodh Iyengar wrote: > > > There is also an alternate world in which the TLS terminators should > not have certificates/keys on them but it is okay to give them > delegated credentials. Here, one benefit is clear: performance. But > the attacker capabilities against which

Re: [TLS] Current TLS 1.3 state?

On 04/05/2017 04:03 AM, Karthikeyan Bhargavan wrote: > We’re hoping that the TLS:DIV workshop later this month will serve to > gather some opinions from the academic community on the current spec. > https://www.mitls.org/tls:div/ >

Re: [TLS] Support of integrity only cipher suites in TLS 1.3

Adding such a mode would add additional complexity that might lead to vulnerabiltiies, e.g. implementations that can be tricked into using a nonencrypted mode. [[stf]] in principle yes, as this simplifies the configuration and policy handling. On the other hand it is a security policy point to a

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > On 04/05/2017 09:21 AM, Eric Rescorla wrote: > > On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi > wrote: > > Does cached-info not represent a privacy info-leak by disclosing past > sessions prior to authenticating the new session? Versus compr

Re: [TLS] Support of integrity only cipher suites in TLS 1.3

Do you have a compelling need for TLS 1.3 as opposed to earlier versions which do have null encryption? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Support of integrity only cipher suites in TLS 1.3

Without taking a position on null cipher suites, I would observe that the new TLS IANA rules will let you register your own (non-standard, non-recommended) code points for integrity-only suites. -Ekr On Wed, Apr 5, 2017 at 10:14 AM, Fries, Steffen wrote: > Adding such a mode would add addition

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin wrote: > On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: > >> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >> >> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >> wrote: >> >> Does cached-info not represent a privacy info-leak by disclosing pas

Re: [TLS] Certificate compression draft

On Wed, Apr 5, 2017 at 10:45 AM, Eric Rescorla wrote: > > > On Wed, Apr 5, 2017 at 10:15 AM, David Benjamin > wrote: > >> On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote: >> >>> On 04/05/2017 09:21 AM, Eric Rescorla wrote: >>> >>> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi >>> wrote: >>>

Re: [TLS] Current TLS 1.3 state?

On Wed, Apr 05, 2017 at 11:03:25AM +0200, Karthikeyan Bhargavan wrote: > What I am less confident about is the secure usage of features like > 0-RTT, 0.5 RTT, and post-handshake authentication. Two of those (0-RTT and post-handshake authentication) are among the the things that scare me. 0.5-RTT

Re: [TLS] Current TLS 1.3 state?

On Wed, Apr 5, 2017 at 2:03 AM, Karthikeyan Bhargavan < karthik.bharga...@gmail.com> wrote: > > What I am less confident about is the secure usage of features like 0-RTT, > 0.5 RTT, and post-handshake authentication. > Many researchers have looked at these aspects (and they can correct me if > I a

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

I've no strong opinion for or against this. One question below though. On 05/04/17 17:07, Subodh Iyengar wrote: > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, > and an attacker can steal private keys durin

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

> With that goal in mind, wouldn't it help mitigate the threat if the holder of the longer term credential (the cert subject) were to include within the signature e.g. an IP address range within which the delegated credential is allowed to be used? We thought about this originally, but we discount

Re: [TLS] security considerations for draft-rescorla-tls-subcerts

On 05/04/17 18:07, Subodh Iyengar wrote: > > The threat model here is that since if a less-trusted host having a > key is compromised for a certain period of time without detection, and > an attacker can steal private keys during that period. In many > situations we are fine with giving the TLS ter