On 13 July 2016 at 13:22, Dave Garrett wrote:
> I am aware that discussion ended up on accepting sloppy error reporting as
> acceptable. Changing the disputed missing_extension alerts to SHOULDs would
> be an acceptable compromise if that decision is still actually going through.
"sloppy" is a
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
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. The
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] https://github.
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, thi
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 filt
On Tue, Jul 12, 2016 at 2:27 PM, Ilari Liusvaara
wrote:
> On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote:
> > > On Jul 11, 2016, at 19:24, Andrei Popov
> wrote:
> > >
> > > Back to the question...
> > > One challenge with this is that exporters are often used to compare
> > > th
On Tue, Jul 12, 2016 at 10:00:35AM -0400, Douglas Stebila wrote:
> > On Jul 11, 2016, at 19:24, Andrei Popov wrote:
> >
> > Back to the question...
> > One challenge with this is that exporters are often used to compare
> > things. For instance, one side signs an exported value, the other
> > va
On Tue, Jul 12, 2016 at 1:31 PM, Benjamin Kaduk wrote:
> 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 short
On Tue, Jul 12, 2016 at 4:17 PM Ilari Liusvaara
wrote:
> On Tue, Jul 12, 2016 at 07:53:41PM +, David Benjamin wrote:
> > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > Right, there is a risk of interop failures if two implementations
> disagre
On Tue, Jul 12, 2016 at 03:31:21PM -0500, Benjamin Kaduk wrote:
> On 07/11/2016 11:16 PM, Ilari Liusvaara wrote:
> > Isn't this the true ciphersuite used on this connection, "resumption"
> > or not? Otherwise you can get into all sorts of crazy situations that
> > WILL be sources of implementation
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 lo
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 algorithms into
> 1.2 is not that
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
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* exist
> > in 1.2 because we'r
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
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* exist
> in 1.2 because we're not touching the 1.2 registries. But this should be
> clarified
Hi
> On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) wrote:
>
> 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 encryptio
Hi,
> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) wrote:
>
> 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
> O
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-
>> From: Paterson, Kenny [m
> -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 18:04
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 AES-GCM under
>the (single) tar
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, "Dang, Quynh (Fed)" wrote:
>>>
Hi Kenny,
I support the strongest
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 extension contained hash/signature pairs. The pair
[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 SignatureScheme values have b
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 indistinguishability notion mentioned in (*)
>>>above, but in my opinion we
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 did not recommend
>>a limit of 2^38 records. That
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,
>>
>>The indistinguishability-based security notion in the paper is a stronger
>>security notion than the (old) traditional confidentiality notion.
>
>Well, indeed, I'm
Hi
On 12/07/2016 16:12, "Dang, Quynh (Fed)" wrote:
>Hi Kenny,
>
>The indistinguishability-based security notion in the paper is a stronger
>security notion than the (old) traditional confidentiality notion.
Well, indeed, I'm somewhat aware of the notion and its emergence over the
years. Indeed,
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 AES-GCM under
>the (single) tar
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 simpli
Ø 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
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,
SecurityParamete
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: TL
Hi Kenny,
The indistinguishability-based security notion in the paper is a stronger
security notion than the (old) traditional confidentiality notion.
(*) Indistinguishability notion (framework) guarantees no other attacks
can be better than the indistinguishability bound. Intuitively, you can¹t
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
> 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 client is both
> Alice and B
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 atta
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 atta
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
> > > is
40 matches
Mail list logo