Hi Martin,
AES_256_CCM_8 was not in the first versions of the draft but added later
after request from IoT people (probably afraid of quantum computers).
While I think it makes very much sense to have short tags in wireless
radio, I do not know how large need there is for AES-256 in IoT for
c
I agree that this is a good idea. Absent objection, i'm going to merge this
PR on Monday
On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin
wrote:
> We were also expecting to want to bound how much traffic a server could be
> compelled to skip over without making progress. It actually didn't occur t
I agree that "I don't like NST or KU" is not a very useful thing to add to
the spec. I added them as part of a general move towards clarity and
conservatism about which types of post-handshake messages are permissible
in TLS 1.3. Right now the spec is ambiguous about what each side of the
connectio
To add to that, in out-of-order transports, whether a message was sent over
0-RTT or not may not even be very well-defined. If QUIC originally sent
data over 0-RTT but had to retransmit it after the full connection
parameters are available, I believe it will use those.
Even in an in-order transpor
On Sat, Oct 8, 2016 at 10:06 AM, Ilari Liusvaara
wrote:
> On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
> >
> > In the APIs people have been designing, 0-RTT can become 1-RTT but not
> the
> > other way around.
> > Specifically:
> >
> > - There is an option to allow 0-RTT writing
On Sat, Oct 08, 2016 at 09:22:40AM -0700, Eric Rescorla wrote:
>
> In the APIs people have been designing, 0-RTT can become 1-RTT but not the
> other way around.
> Specifically:
>
> - There is an option to allow 0-RTT writing
> - With that option on, SSL_Write() succeeds in both 0-RTT and 1-RTT mo
I could go either way on this. It seems like this pushes complexity from
the client to the server.
Consider the case of NST. Presently, a client which doesn't want resumption
can just ignore NST,
but in your proposed change, the server needs to read this extension and
then conditionally send
NST,
On Sat, Oct 08, 2016 at 04:32:32PM +, Nick Sullivan wrote:
> I'm not proposing any new post-handshake authentication mechanisms or
> anything relating to HTTP/2 renegotiation in this change. I'm simply making
> support for the existing post-handshake messages optional.
>
> With this change, if
Right, but making it an extension does not really capture the complexities
of post-handshake auth. What's needed is mostly spec text, not wire
changes. The text should say something to the effect of unexpected
CertificateRequests are always fatal to the connection. By default, all
CertificateReques
I'm not proposing any new post-handshake authentication mechanisms or
anything relating to HTTP/2 renegotiation in this change. I'm simply making
support for the existing post-handshake messages optional.
With this change, if the client does not opt in, unexpected
CertificateRequests are fatal to
On Sat, Oct 8, 2016 at 7:25 AM, Watson Ladd wrote:
> On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote:
> >
> >
> > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >>
> >> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> >> > On Fri, Sep
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is an
> attempt to make the story m
On Fri, Oct 7, 2016 at 3:04 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
> wrote:
>>
>> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
>> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
>> > wrote:
>> > >
>> > > Also, it is very likely that 0-R
On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
> wrote:
>
> > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> > > wrote:
> > > >
> > > > Also, it is very likel
On Fri, Oct 07, 2016 at 01:41:48PM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote:
>
> > On 10/07/2016 12:08 PM, Eric Rescorla wrote:
> >
> >
> >
> > On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > > wrote:
> >
> >> On Fri, Oct 07, 2016 at 09:35:40AM -0700,
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussion lately about post-handshake messages
> that do not contain application data and how to handle them. This PR is an
> attempt to make the story more explicit by adding a new post_handshake
> extension
16 matches
Mail list logo
