Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

On Tue, Jul 12, 2016 at 01:52:57AM -0400, Dave Garrett wrote: > Just replying to a few points. > > On Tuesday, July 12, 2016 12:16:24 am Ilari Liusvaara wrote: > > ### Hello Retry Request > > > > > selected_group > > > : The mutually supported group the server intends to negotiate and > > >

[TLS] Server-side missing_extension MUSTs

Hey folks, I would like to remove the missing_extension MUSTs on the server side. Full justification in the PR. https://github.com/tlswg/tls13-spec/pull/544 On the client, it is perfectly feasible to mandate a particular alert value. The check is very straight-forward. On the server, however,

Re: [TLS] Server-side missing_extension MUSTs

I generally agree with David here. -Ekr P.S. Back in Seattle, we had rough consensus to change the alert requirements [0] so that you didn't have to send alerts, but if you sent an alert, you had to send alert X. That's been on the TODO list for a while but expect a PR soon. [0]

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

On 07/12/2016 04:07 PM, Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote: >> On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: >> >> Requiring filtering would prevent the client from learning when the >> server supports new schemes, but having the server not

Re: [TLS] Server-side missing_extension MUSTs

On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote: > I would like to remove the missing_extension MUSTs on the server side. Full > justification in the PR. > https://github.com/tlswg/tls13-spec/pull/544 > > On the client, it is perfectly feasible to mandate a particular alert > value.

Re: [TLS] Server-side missing_extension MUSTs

On Tuesday, July 12, 2016 10:51:22 pm Eric Rescorla wrote: > I generally agree with David here. > > -Ekr > > P.S. Back in Seattle, we had rough consensus to change the alert requirements > [0] so that > you didn't have to send alerts, but if you sent an alert, you had to send > alert X. That's

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Quynh, This indistinguishability-based security notion is the confidentiality notion that is by now generally accepted in the crypto community. Meeting it is sufficient to guarantee security against many other forms of attack on confidentiality, which is one of the main reasons we use it. You

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Eric and all, In my opinion, we should give better information about data limit for AES_GCM in TLS 1.3 instead of what is current in the draft 14. In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called confidentiality attack is the known plaintext differentiality

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

> On Jul 11, 2016, at 19:24, Andrei Popov wrote: > > As currently defined, post-handshake client auth allows the same client to > present different identities, but not to repudiate a previously presented > identity. So in your example, from the TLS perspective, the

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 1:47 PM David Benjamin wrote: > [Changing subject since the other thread is about something else.] > > On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara > wrote: > >> > ### Signature Algorithms >> > >> > * In TLS 1.2, the

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Eric and all, In my opinion, we should give better information about data limit for AES_GCM in TLS 1.3 instead of what is current in the draft 14. In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf, what is called confidentiality attack is the known plaintext differentiality

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Kenny, On 7/12/16, 12:33 PM, "Paterson, Kenny" wrote: >Unfortunately, that's not quite the right interpretation. The bounds one >obtains depend on both the total amount of data encrypted AND the number >of encryption queries the adversary is allowed to make to

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi Kenny, On 7/12/16, 1:39 PM, "Paterson, Kenny" wrote: >Hi > >On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote: > >>Hi Kenny, >> >>On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote: >> >>>Hi >>> >>>On 12/07/2016 16:12,

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

> -Original Message- > From: Paterson, Kenny [mailto:kenny.pater...@rhul.ac.uk] > Sent: Tuesday, July 12, 2016 1:17 PM > To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt > > Hi > > On 12/07/2016

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Actually, a more correct way of viewing the limit would be 2^52 encrypted data bytes. To come to the 2^38 record limit, they assume that each record is the maximum 2^14 bytes. Of course, at a 1Gbps rate, it'd take over a year to encrypt that much data... > -Original Message- > From:

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

Ø IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values do not change. Is this correct? EKM mixes in client and server randoms, which are hopefully different in each resumption. Cheers, Andrei From: Bill Cox [mailto:waywardg...@google.com] Sent: Tuesday, July 12, 2016 8:35

Re: [TLS] Should exporter keys be updated with post-handshake authentication and/or KeyUpdate?

On Tue, Jul 12, 2016 at 8:34 AM, Bill Cox wrote: > IIRC, in TLS 1.2 the same keys are used after resumption, and EKM values > do not change. > In TLS 1.2, the EKM == MS but the exporter includes the randoms: PRF(SecurityParameters.master_secret, label,

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi On 12/07/2016 18:04, "Dang, Quynh (Fed)" wrote: >Hi Kenny, > >On 7/12/16, 12:33 PM, "Paterson, Kenny" wrote: > >>Finally, you write "to come to the 2^38 record limit, they assume that >>each record is the maximum 2^14 bytes". For clarity, we

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Hi On 12/07/2016 18:12, "Dang, Quynh (Fed)" wrote: >Hi Kenny, > >On 7/12/16, 1:05 PM, "Paterson, Kenny" wrote: > >>Hi >> >>On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote: >> >>>Hi Kenny, >>> >>>I support the strongest

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Unfortunately, that's not quite the right interpretation. The bounds one obtains depend on both the total amount of data encrypted AND the number of encryption queries the adversary is allowed to make to AES-GCM under the (single) target key. We assumed each record was 2^14 bytes in size to

[TLS] TLS 1.3 signature algorithms in TLS 1.2

[Changing subject since the other thread is about something else.] On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara wrote: > > ### Signature Algorithms > > > > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are > > encoded in two octets, so

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Yup, that's crypto, folks. These are the kinds of numbers we should be worrying about for a protocol that will be deployed for decades to billions of people and devices. > On 12 Jul 2016, at 19:06, Scott Fluhrer (sfluhrer) wrote: > > >> -Original Message- >>

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 07:53:41PM +, David Benjamin wrote: > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara > wrote: > > Right, there is a risk of interop failures if two implementations disagree > on whether the algorithms exist in 1.2. Since getting these

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

On 07/11/2016 11:16 PM, Ilari Liusvaara wrote: > On Mon, Jul 11, 2016 at 12:08:00PM -0700, Eric Rescorla wrote: >> Folks, >> >> I've just submitted draft-ietf-tls-tls13-14.txt and it should >> show up on the draft repository shortly. In the meantime you >> can find the editor's copy in the usual

Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt

To be clear, this probability is that an attacker would be able to take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential (but incorrect) plaintext, and with probability 2^{-32}, be able to determine that this plaintext was not the one used for the ciphertext (and with probability

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara wrote: > On Tue, Jul 12, 2016 at 05:47:26PM +, David Benjamin wrote: > > [Changing subject since the other thread is about something else.] > > > > I believe, as the text stands right now, RSA-PSS and EdDSA do *not*

Re: [TLS] TLS 1.3 signature algorithms in TLS 1.2

On Tue, Jul 12, 2016 at 10:29:29PM +0300, Ilari Liusvaara wrote: > By the time CertificateRequest is sent, the server knows the final > protocol, so it can omit algorithms it knows it can't handle. Also, > the client picks the actual algorithm, so it too can avoid algorithms > it can't handle. So