With respect to communicating policy from the application layer to the
TLS stack, what's wrong with David's "CertificateRequest is disallowed
by default, and the application must make a library call to enable it
for a given connection/context" proposal? It seems fairly
straightforward in terms of
I agree with MT. Hannes, if you want to clean up the text to take into
account MT's comments, I will merge
On Sat, Sep 10, 2016 at 3:35 AM, Martin Thomson
wrote:
> On 9 September 2016 at 23:37, Hannes Tschofenig
> wrote:
> > I am wondering
On Mon, Oct 10, 2016 at 1:49 PM, Watson Ladd wrote:
>
> The problem is with poorly-behaved senders and attackers resending
> 0-RTT data. Receivers should be able to ensure side-effectfull
> operations are not carried out by 0-RTT data. Making 0-RTT silent in
> APIs
Merged
On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla wrote:
> 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
On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin wrote:
> 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
2016-10-07 22:06 GMT+ David Benjamin :
> Units is a little interesting. For those purposes, this limit would
> kick in whether or not the early data could be decrypted, so the server-
> side limit would be measured in ciphertext, possibly even including
> record headers.
Geoffrey Keating wrote:
>
> A typical macOS system will have many issued certs, typically with at
> most one that will work for any particular web site or web API. So
> the filter is somewhat important for client certs to work there in any
> kind of user-friendly way. In particular if the