I've uploaded the chair’s slides and the other presentations I’ve received to
date:
https://datatracker.ietf.org/meeting/agenda/
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
The known_configuration mechanism in the current draft allows the
client to resurrect the handshake parameters (though not the keys)
which were negotiated in a previous handshake, but this is done
implicitly, i.e., the server provides a label and the client returns
it on the next connection. This h
On 21 July 2015 at 04:04, Eric Rescorla wrote:
> - The client indicates configuration ID and cryptographic configuration,
> including the cipher suites and cryptographic extensions. This
> MUST replicate the server's selection from a previous handshake
That's not going to work if there was n
On Tue, Jul 21, 2015 at 1:10 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:04, Eric Rescorla wrote:
> > - The client indicates configuration ID and cryptographic configuration,
> > including the cipher suites and cryptographic extensions. This
> > MUST replicate the server's selection fr
On 21 July 2015 at 04:12, Eric Rescorla wrote:
>
> Yes, that's an issue. Not entirely sure what to do about other than
> have the server provide its negotiation preferences out of band
> in that case.
I think that we could handle that at the point we define an
out-of-band configuration priming me
Yeah, or it could just have the semantics "this is my most preferred
configuration and if you send me anything compatible with it, I will
pick it"
-Ekr
On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
wrote:
> On 21 July 2015 at 04:12, Eric Rescorla wrote:
> >
> > Yes, that's an issue. Not ent
On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson
> wrote:
>
> > On 21 July 2015 at 04:12, Eric Rescorla wrote:
> > >
> > > Yes, that's an issue. Not entirely sure what to do about other than
> > > have the server provide its negotia
On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> > On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >
> > > On 21 July 2015 at 04:12, Eric Rescorla wr
On Tue, Jul 21, 2015 at 02:55:33PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
>
> > For 0-RTT/Early handshake data you want cipher that the server
> > supports and accepts. If it is about this, there could be multiple
> >
On 7/21/2015 9:21 AM, Michael StJohns wrote:
FYI - This is my long delayed KDF document. I think its late enough
that it isn't a useful submission for TLS1.3, but I would appreciate any
feedback on it. It may eventually be useful for the next group of
protocol revisions.
Thanks - Mike
On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> Well, if it is about supported ciphers, there could be multiple, and
> the proposal has slot for only one.
The proposal is for what the client selects and uses for its first flight.
___
TLS mailing li
On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> On 21 July 2015 at 06:08, Ilari Liusvaara wrote:
> > Well, if it is about supported ciphers, there could be multiple, and
> > the proposal has slot for only one.
>
> The proposal is for what the client selects and uses for its firs
Rene Struik schrieb am 16.07.2015 um 03:42:
> Dear colleagues:
>
> It seems prudent to keep some diversity of the gene pool and not only have
> curves defined over prime curves. Similarly,
> one should perhaps have some diversity of gene pool criteria within the set
> of recommend curves and not
On Tue, Jul 21, 2015 at 04:39:17PM +0200, Johannes Merkle wrote:
>
> I absolutely back up this position. Currently, the TLS 1.3 draft only permits
> curves over special primes. It has become
> quite clear in the discussions in CFRG and at the NIST ECC workshop that some
> parties (major hardware
On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 06:38:28AM -0700, Martin Thomson wrote:
> > On 21 July 2015 at 06:08, Ilari Liusvaara
> wrote:
> > > Well, if it is about supported ciphers, there could be multiple, and
> > > the prop
On Tue, Jul 21, 2015 at 05:09:31PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 4:15 PM, Ilari Liusvaara <
> ilari.liusva...@elisanet.fi> wrote:
> >
> > Also, with regard to ending 0RTT, even without encrypted content
> > types. Either I am misunderstanding something, or:
> >
> > - Client:
On 21 July 2015 at 08:17, Ilari Liusvaara wrote:
>> > *deadlock*.
>>
>>
>> Is this the case where the server is accepting 0-RTT or rejecting it?
>
> Apparently, only for accepting case.
>
> (If the server rejects, it can reply immediately, avoiding this
> deadlock).
I don't think that this is a
On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> I thought that Brainpool curves weren't removed (even if those aren't
> explicitly in), which are random prime curves.
>
> Also, the security of binary curves seems quite questionable.
Brainpool curves aren't in the TLS 1.3 draft, but
On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote:
> struct {
>select (Role) {
> case client:
>opaque identifier<0..2^16-1>;
>CipherSuite cipher_suite;// NEW
>Extension extensions<0..2^16-1>; /
On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote:
> On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> > I thought that Brainpool curves weren't removed (even if those aren't
> > explicitly in), which are random prime curves.
> >
> > Also, the security of binary curves seem
On Tue, Jul 21, 2015 at 7:20 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:
> On Tue, Jul 21, 2015 at 11:30:15AM -0400, Dave Garrett wrote:
> > On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> > > I thought that Brainpool curves weren't removed (even if those aren't
> > >
On Tue, Jul 21, 2015 at 5:21 PM, Martin Thomson
wrote:
> On 21 July 2015 at 08:17, Ilari Liusvaara
> wrote:
> >> > *deadlock*.
> >>
> >>
> >> Is this the case where the server is accepting 0-RTT or rejecting it?
> >
> > Apparently, only for accepting case.
> >
> > (If the server rejects, it can
I've updated the a la carte proposal again with some improvements to
readability. I've also added in the ECDHE PSK cipher suites in the current
draft, as they are required for this.
current WIP text:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites
di
23 matches
Mail list logo
