Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

2016-10-10 Thread Martin Thomson
On 11 October 2016 at 14:30, Benjamin Kaduk wrote: > So, on the balance, I think I'm starting to lean against this specific > proposal and more towards the text changes that David wants. Yes, I would rather not take NST or KU out of the mandatory set of 1.3 features. I'm happy to have post-hands

Re: [TLS] Application layer interactions and API guidance

2016-10-10 Thread Martin Thomson
On 11 October 2016 at 07:57, Kyle Rose wrote: > FWIW, Patrick McManus made a pretty eloquent and convincing case in Berlin > that the web is substantially broken without retry logic in the browsers, > that naturally make application-level replay mitigation a necessity. But I > don't think (nor do

Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

2016-10-10 Thread Benjamin Kaduk
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

Re: [TLS] Zero-RTT Data & PSK

2016-10-10 Thread Eric Rescorla
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 why I cannot use Zero-RTT with just PSK-based > authent

Re: [TLS] Application layer interactions and API guidance

2016-10-10 Thread Kyle Rose
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 transforms an interoperability

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

2016-10-10 Thread Eric Rescorla
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 bound how much traffic a server could >> be

Re: [TLS] Application layer interactions and API guidance

2016-10-10 Thread Watson Ladd
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 connection parameters are > avail

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

2016-10-10 Thread Filippo Valsorda
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. (Although any inaccurac

Re: [TLS] CertficateRequest extension encoding

2016-10-10 Thread Martin Rex
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 server