Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

2018-11-07 Thread David Benjamin
On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni wrote: > [ Quoted text slightly reordered to put the RSA issue first, as that's > the main thing I'm trying to get clarity on, and enabling keyUsage > enforcement is causing some interoperability issues now... ] > > > On Nov 5, 2018, at 11:11

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Tommy Pauly
As a co-author, I do support adoption, as this will help optimize client connection racing. Tommy > On Nov 8, 2018, at 8:07 AM, Martin Thomson wrote: > > Adopt it. It's a small, useful feature. > On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote: >> >> At TLS@IETF103, there was consensus in

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Martin Thomson
Adopt it. It's a small, useful feature. On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote: > > At TLS@IETF103, there was consensus in the room to adopt > draft-wood-tls-ticketrequests. This message is to confirm that consensus. > If you do not support adoption of draft-wood-tls-ticketrequests

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Salz, Rich
I support adoption and I am sure OpenSSL will implement, or I will do it and make a PR. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

[TLS] Are we holding TLS wrong?

2018-11-07 Thread David Schinazi
Hi everyone, Over in the Babel working group we have a draft about securing Babel with DTLS: https://tools.ietf.org/html/draft-ietf-babel-dtls-01 It's 5 pages long, could any TLS experts please give it a quick read and let us know if we're using DTLS correctly? Also, should the document contain

Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

2018-11-07 Thread Peter Gutmann
Viktor Dukhovni writes: >On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote: >> There is *ZERO* security problem associated with TLS client allowing >> a TLS server to do this, but it makes it harder to catch defective >> CA software and bogus CA issuing practices when clients do not

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

2018-11-07 Thread Viktor Dukhovni
> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating wrote: > > n general, though, what you're asking is "The CA signing this key has > instructed that I do not accept signatures made with it. Is it OK to > accept signatures made with it?" It's really hard to see how the > answer to that could

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Filippo Valsorda
+1 to adoption. I found myself unsure of how many tickets to send in the new Go implementation, which is notoriously averse to configuration knobs, and would love to have the client pick. 2018-11-07 14:47 GMT+0700 Sean Turner : > At TLS@IETF103, there was consensus in the room to adopt

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Eric Kinnear
I support adoption, this seems straightforward and is a good solution to a real world problem I’ve got. Thanks, Eric > On Nov 8, 2018, at 9:44 AM, Daniel Migault > wrote: > > I support the adoption as well, we need it for lurk. > Yours, > Daniel > >> On Wed, Nov 7, 2018 at 8:31 PM Salz,

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

2018-11-07 Thread Daniel Migault
I support the adoption as well, we need it for lurk. Yours, Daniel On Wed, Nov 7, 2018 at 8:31 PM Salz, Rich wrote: > I support adoption and I am sure OpenSSL will implement, or I will do it > and make a PR. > > ___ > TLS mailing list > TLS@ietf.org >

Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

2018-11-07 Thread Blumenthal, Uri - 0553 - MITLL
Peter, I think your code did exactly right. The standard requires honoring KeyUsage.. Maybe if more implementations were diligent with this, the cert zoo we're observing would've been less wild... Regards, Uri Sent from my iPhone > On Nov 7, 2018, at 21:21, Peter Gutmann wrote: > > Viktor

Re: [TLS] Are we holding TLS wrong?

2018-11-07 Thread Fossati, Thomas (Nokia - GB/Cambridge)
Hi David, A few quick notes below. Cheers The 11/08/2018 09:14, David Schinazi wrote: > Hi everyone, > > Over in the Babel working group we have a draft about securing Babel with > DTLS: > https://tools.ietf.org/html/draft-ietf-babel-dtls-01 > > It's 5 pages long, could any TLS experts please

Re: [TLS] Are we holding TLS wrong?

2018-11-07 Thread Hannes Tschofenig
I took a quick look at the document and I don't know Babel.    I see that you have two different proposals for securing Babel messages, namely  * DTLS, and  * a custom format offering integrity protection only.    You correctly note in the document that DTLS offers more features. It is an

Re: [TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2018-11-07 Thread Stephen Farrell
Hiya, This version attempts to make the few changes discussed at the meeting on Monday. I wrote a script that gave me a list of 76(!) RFCs this might need to update, and may of course have mucked that up, so if anyone has a chance to check if (some of) those make sense, that'd be great. Ta, S.

[TLS] I-D Action: draft-ietf-tls-oldversions-deprecate-01.txt

2018-11-07 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 : Deprecating TLSv1.0 and TLSv1.1 Authors : Kathleen Moriarty Stephen

Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

2018-11-07 Thread Martin Rex
Geoffrey Keating wrote: > Viktor Dukhovni writes: >> >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer >> certificate that *only* lists: >> >> X509v3 Key Usage: >> Key Encipherment, Data Encipherment > > Yes, because in DHE-RSA, the RSA key is used

Re: [TLS] Certificate keyUsage enforcement [whose duty, client's or server's?]

2018-11-07 Thread Viktor Dukhovni
On Wed, Nov 07, 2018 at 03:48:26PM +0100, Martin Rex wrote: > There is *ZERO* security problem associated with TLS client allowing > a TLS server to do this, but it makes it harder to catch defective > CA software and bogus CA issuing practices when clients do not complain > here The