Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Rob Sayre
On Thu, Oct 3, 2019 at 10:19 AM Christopher Wood wrote: > On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood > wrote: > > > > > > > I understand the meaning of count is the higher limit of ticket and > the > > > > server can provides any

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Viktor Dukhovni
> On Oct 2, 2019, at 11:20 PM, Christopher Wood wrote: > > Asking for one upon resumption seems reasonable to me. Thanks to you and > Viktor for bringing up this case! Thanks! Much appreciated. My other point, which I probably obscured in too many words, is that a client that prefers to

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Christopher Wood
On Wed, Oct 2, 2019, at 4:04 PM, Nico Williams wrote: > On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > > I've read the draft, it looks quite useful and reasonable. It would > > be good to see this published. > > +1 > > > I have one idea (implemented in OpenSSL 1.1.1 on the

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Christopher Wood
On Wed, Oct 2, 2019, at 8:08 PM, Rob Sayre wrote: > On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > > > I understand the meaning of count is the higher limit of ticket and the > > > server can provides any tickets between 0 and count. If that is > > > correct, this could be

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Rob Sayre
On Thu, Oct 3, 2019 at 3:54 AM Christopher Wood wrote: > > > I understand the meaning of count is the higher limit of ticket and the > > server can provides any tickets between 0 and count. If that is > > correct, this could be clearly stated and indication to chose an > > appropriated value for

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Nico Williams
On Tue, Oct 01, 2019 at 10:56:00AM -0400, Viktor Dukhovni wrote: > I've read the draft, it looks quite useful and reasonable. It would > be good to see this published. +1 > I have one idea (implemented in OpenSSL 1.1.1 on the server side) > that may be worth mentioning in this context (and

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Daniel Migault
Hi, Please see my comments. Yours, Daniel On Wed, Oct 2, 2019 at 4:55 PM Christopher Wood wrote: > Hi Daniel, > > Please see inline below. > > On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > > Hi, > > > > Please find some comments on the draft. > > > > In the introduction, I believe

[TLS] IANA changes for draft-ietf-tls-exported-authenticator

2019-10-02 Thread Christopher Wood
Hi folks, draft-ietf-tls-exported-authenticator requires some IANA changes that were not discussed during WGLC. The proposed changes are below. Please let the list know by next week (10/9) if you object to them, and if so, please explain why. > Value: EXPORTER-server authenticator handshake

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

2019-10-02 Thread Christopher Wood
Hi Daniel, Please see inline below. On Wed, Oct 2, 2019, at 1:42 PM, Daniel Migault wrote: > Hi, > > Please find some comments on the draft. > > In the introduction, I believe both limitations may be merged into one > limitation which is the number of ticket is a server only decision. The

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

2019-10-02 Thread Blumenthal, Uri - 0553 - MITLL
I concur with Hubert, and think that DER in this context is perfectly OK. On 10/2/19, 6:59 AM, "TLS on behalf of Hubert Kario" wrote: On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :)

Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

2019-10-02 Thread John Mattsson
Hi, Sean Turner wrote: > "You can change the text, but I do not believe it will change the > implementations." I would much rather have a future proof RFC that forbids negotiation of DTLS 1.0 with the knowledge that some implementations will temporary violate that, than having an RFC that

Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt

2019-10-02 Thread Christopher Wood
Oops. Here are the referenced links: [1] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/pull/10 [2] https://github.com/tlswg/draft-ietf-tls-external-psk-importer/issues/20 On Wed, Oct 2, 2019, at 6:54 AM, Christopher Wood wrote: > This update includes recent feedback received on

Re: [TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt

2019-10-02 Thread Christopher Wood
This update includes recent feedback received on the list and GitHub. There are three major changes: - Target KDFs instead of hash algorithms when importing external PSKs - Add an opaque "context" slot to the ImportedIdentity struct and describe its use for Selfie mitigations - Remove backwards

[TLS] I-D Action: draft-ietf-tls-external-psk-importer-01.txt

2019-10-02 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Importing External PSKs for TLS Authors : David Benjamin Christopher A.

Re: [TLS] DTLS Key Separation PR

2019-10-02 Thread Sean Turner
Since this had support in the room, we would really like to get a sense if there are any objections to this. Baring any negative comments, we’ll ask ekr to merge this on 10/7. spt > On Oct 1, 2019, at 23:40, Eric Rescorla wrote: > > Hi folks, > > As discussed in Montreal, I've prepared a

Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

2019-10-02 Thread Stephen Farrell
Hiya, On 02/10/2019 14:17, Sean Turner wrote: > You can change the text, but I do not believe it will change the > implementations. I would leave the text as is and NOT do an updates > header. WFM. I have executed that NOOP:-) S. 0x5AB2FAF17B172BEA.asc Description: application/pgp-keys

Re: [TLS] Publication has been requested for draft-ietf-tls-oldversions-deprecate-05

2019-10-02 Thread Sean Turner
> On Oct 1, 2019, at 21:14, Eric Rescorla wrote: > > > > On Tue, Oct 1, 2019 at 1:04 AM John Mattsson > wrote: > Hi, > > I think draft-ietf-tls-oldversions-deprecate needs to update > draft-ietf-rtcweb-security-arch as well. > > draft-ietf-rtcweb-security-arch-20 uses DTLS and even

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

2019-10-02 Thread Sean Turner
> On Oct 2, 2019, at 12:23, Hubert Kario wrote: > > Signed PGP part > On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: >> On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: >>> On Tue, Oct 1, 2019 at 5:27 AM John Mattsson >> >>> 40ericsson@dmarc.ietf.org> wrote:

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

2019-10-02 Thread Hubert Kario
On Wednesday, 2 October 2019 13:18:07 CEST Hubert Kario wrote: > On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson > > > 40ericsson@dmarc.ietf.org> wrote: > > > Dan Brown wrote: > > > > ANSI X9.62-2005 was withdrawn in 2015 > > >

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

2019-10-02 Thread Hubert Kario
On Tuesday, 1 October 2019 17:01:54 CEST Eric Rescorla wrote: > On Tue, Oct 1, 2019 at 5:27 AM John Mattsson > 40ericsson@dmarc.ietf.org> wrote: > > Dan Brown wrote: > > > ANSI X9.62-2005 was withdrawn in 2015 > > > > Ok, that TLS 1.3 is relying on a withdrawn publication that used to be >

[TLS] [Technical Errata Reported] RFC8446 (5868)

2019-10-02 Thread RFC Errata System
The following errata report has been submitted for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid5868 -- Type: Technical

Re: [TLS] Ecdsa-sig-value in TLS 1.3 – need for erratum?

2019-10-02 Thread Hubert Kario
On Wednesday, 2 October 2019 00:15:13 CEST Peter Gutmann wrote: > Hubert Kario writes: > >a lax DER parser sounds like an oxymoron to me... :) > > That's why I assumed it was an accident/error. Writing a spec that relies > on buggy parser implementations in order to work is asking for trouble.