Re: [TLS] Alerts after early_data

2018-08-08 Thread Hubert Kario
On Wednesday, 8 August 2018 13:26:29 CEST Matt Caswell wrote: > On 08/08/18 12:13, Hubert Kario wrote: > > On Tuesday, 7 August 2018 10:35:40 CEST Matt Caswell wrote: > >> If a client has sent early_data and later encounters an error before it > >> has sent the end of early data message, should the

Re: [TLS] Alerts after early_data

2018-08-08 Thread Matt Caswell
On 08/08/18 12:13, Hubert Kario wrote: > On Tuesday, 7 August 2018 10:35:40 CEST Matt Caswell wrote: >> If a client has sent early_data and later encounters an error before it >> has sent the end of early data message, should the alert be sent in >> plaintext, or encrypted using the client_early

Re: [TLS] Alerts after early_data

2018-08-08 Thread Hubert Kario
On Tuesday, 7 August 2018 10:35:40 CEST Matt Caswell wrote: > If a client has sent early_data and later encounters an error before it > has sent the end of early data message, should the alert be sent in > plaintext, or encrypted using the client_early_traffic secret? The error > could occur before

[TLS] Alerts after early_data

2018-08-07 Thread Matt Caswell
If a client has sent early_data and later encounters an error before it has sent the end of early data message, should the alert be sent in plaintext, or encrypted using the client_early_traffic secret? The error could occur before or after the client knows whether the server has accepted its early

Re: [TLS] Alerts

2017-05-12 Thread Matt Caswell
On 11 May 2017 at 21:06, Viktor Dukhovni wrote: > >> On May 11, 2017, at 4:21 AM, Matt Caswell wrote: >> >> If the view is that the more specific alerts are helpful, then I'd >> suggest amending the wording in the "Server Certificate Selection" >> section to remove the bit about the "unsupported_

Re: [TLS] Alerts

2017-05-11 Thread Viktor Dukhovni
> On May 11, 2017, at 4:21 AM, Matt Caswell wrote: > > If the view is that the more specific alerts are helpful, then I'd > suggest amending the wording in the "Server Certificate Selection" > section to remove the bit about the "unsupported_certificate" alert > and (possibly) replace with a ref

Re: [TLS] Alerts

2017-05-11 Thread Matt Caswell
On 10 May 2017 at 21:51, Martin Thomson wrote: > On 11 May 2017 at 01:21, Matt Caswell wrote: >> Do we really need all of these alerts? > > NSS uses these, but in ways that I don't really understand. I think > that this is part of the general issue that TLS does and doesn't > really include requ

Re: [TLS] Alerts

2017-05-10 Thread Martin Thomson
On 11 May 2017 at 01:21, Matt Caswell wrote: > Do we really need all of these alerts? NSS uses these, but in ways that I don't really understand. I think that this is part of the general issue that TLS does and doesn't really include requirements about how to handle the certificate chain. _

[TLS] Alerts

2017-05-10 Thread Matt Caswell
Draft-20 currently contains this text in the section "Server Certificate Selection": 'If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an"unsupported_certificate" alert."' However, section

[TLS] Alerts & Certs - PR #201

2015-07-16 Thread Dave Garrett
https://github.com/tlswg/tls13-spec/pull/201 I've finished up the WIPs I had been working on for the various discussions we've been having on-list and submitted a PR. There's a lot in there, so review and comments are welcome. Almost all of this has been discussed here at some point to some deg