Re: [TLS] Questions on certificate_extensions...

> So (for example) it would be a BIT STRING for Key Usage and a SEQUENCE OF > OBJECT IDENTIFIER for Extended Key Usage. This is correct. The idea is to use the same format your PKI library already knows how to deal with. > As regards the matching rules. How do these apply when a particular

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On 15 February 2017 at 03:18, David Wong wrote: > Oups, my bad. What about if the client do send a certificate, but the server > decides not to accept it, but goes on with the connection (I think nothing > in the spec says that the server needs to terminate the

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

> On 14 Feb 2017, at 23:52, Atul Luykx wrote: > >> Why is that 2^48 input blocks rather than 2^34.5 input blocks? > Because he wants to lower the security level. The original text recommends > switching at 2^{34.5} input blocks, corresponding to a success

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Why is that 2^48 input blocks rather than 2^34.5 input blocks? Because he wants to lower the security level. The original text recommends switching at 2^{34.5} input blocks, corresponding to a success probability of 2^{-60}, whereas his text recommends switching at 2^{48} blocks, corresponding

[TLS] Questions on certificate_extensions...

A couple of questions on the format and handling of certificate_extensions. What format is the data that appears in certificate_extension_values? I'd say that it should be in the same format as the content octets of the extnValue field of Extension (from RFC5280 et al). So (for example) it would

Re: [TLS] ticket_lifetime and generic network layer

Thanks for taking the time to read and respond to my queries, my understanding of this protocol is incomplete, but I am working hard to remedy that. On 09/02/17 19:05, Ilari Liusvaara wrote: On Thu, Feb 09, 2017 at 12:38:50PM -, Mark Dunn wrote: I am reading your TLS 3.1 Standard and the

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi, Quynh > On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) wrote: > > Hi Sean and all, > > Beside my suggestion at > https://www.ietf.org/mail-archive/web/tls/current/msg22381.html > , I have a > second

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Sean and all, Beside my suggestion at https://www.ietf.org/mail-archive/web/tls/current/msg22381.html, I have a second suggestion below. Just replacing this sentence: " For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi Atul, From: Atul Luykx > Date: Tuesday, February 14, 2017 at 11:17 AM To: 'Quynh' > Cc: Markulf Kohlweiss >, Antoine

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

Is it important for the client to know, from the TLS stack itself, whether client authentication succeeded or not? My assumption (perhaps incorrect) has been that it is the server that cares about the client's identity (or identities) in order to make an authorization decision. This thread

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Feb 14 2017, at 4:44 pm, David Benjamin wrote: NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it.Oups, my bad. What about if the

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hey Quynh, When someone says AES-128 has 128 bits of security he or she means that 2^128 AES operations will break the cipher with probability 100%: finding the key and the plaintext. The claim is stronger: regardless of the number of plaintext-ciphertext pairs available to the adversary, it

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

On Mon, Feb 13, 2017 at 12:32:53PM +, Cas Cremers wrote: > > The main takeaway is that the client never really receives any > acknowledgement of whether the verification provided was successful or > rejected through an in-band mechanism. > > The context of the keys does not include the

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

NewSessionTicket always includes in-handshake client auth. The resumption secret can't even be derived without it. On Tue, Feb 14, 2017 at 10:21 AM David Wong wrote: > I can see this problem even in the case where the client sends an empty > Certificate message

Re: [TLS] Awkward Handshake: Possible mismatch of client/server view on client authentication in post-handshake mode in Revision 18

I can see this problem even in the case where the client sends an empty Certificate message during the handshake. If the application does not tell the client what happened, a NewSessionTicket has no way of indicating if it will include client-auth in the next session.David