[TLS] draft-ietf-tls-tls13-16

I just uploaded draft-16. https://tools.ietf.org/html/draft-ietf-tls-tls13-16 The primary changes are listed below. - New version negotiation format (*) [IMPORTANT: this got lost in the ChangeLog] - Change RSASSA-PSS and EdDSA SignatureScheme codepoints for better backwards compatibility

Re: [TLS] CertficateRequest extension encoding

On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov wrote: > But it's OID-specific how the matching works, isn't it? Correct, and initially we define matching for KU and EKU. These are the OIDs I've got the most customer requests for. I expect that we will want to define

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 4:59 PM, Hugo Krawczyk wrote: > On Thu, Sep 22, 2016 at 7:50 PM, Colm MacCárthaigh > wrote: > >> On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk >> wrote: >> >>> If the problem is the use of forward

Re: [TLS] Proposed Change to Certificate message (#654)

Nick Sullivan wrote: > PR: https://github.com/tlswg/tls13-spec/pull/654 > > This change adds a set of extensions to the Certificate message. With this > change, the Certificate message can now hold all extension messages that > are certificate-specific (rather than

[TLS] Proposed Change to Certificate message (#654)

PR: https://github.com/tlswg/tls13-spec/pull/654 Hello, I'd like to propose a small to the Certificate message format to allow for future extensibility of the protocol. This change adds a set of extensions to the Certificate message. With this change, the Certificate message can now hold all

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 4:41 PM, Hugo Krawczyk wrote: > If the problem is the use of forward secrecy then there is a simple > solution, don't use it. > That is, you can, as a server, have a fixed key_share for which the secret > exponent becomes the private key exactly as

Re: [TLS] Proposed Change to Certificate message (#654)

This suggestion makes sense to me. Both the SCT and OCSP v2 extension allow for multiple objects in order to cover multiple certificates in a chain, but your suggestion makes the grouping much more explicit and obviates the need for OCSPv2. I'd definitely consider a modification like this. Nick

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 8:53 PM, Geoffrey Keating wrote: > Ryan Carboni writes: > > > in the internet of things, DH is actually > > less secure than normal public key exchange. Servers are more likely to > > have entropy than embedded devices. > > I think

Re: [TLS] Industry Concerns about TLS 1.3

Ryan Carboni writes: > in the internet of things, DH is actually > less secure than normal public key exchange. Servers are more likely to > have entropy than embedded devices. I think that's backwards; in a 'normal' public key exchange, it is the client that generates the

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

On 23 September 2016 at 00:47, Viktor Dukhovni wrote: >> I see your point here. However, where would you draw the line between "I >> can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in >> a ClientHello. You can still find one cipher suite that

Re: [TLS] Industry Concerns about TLS 1.3

Hi Andrew, ? Unfortunately, Microsoft does not allow this functionality, which is a problem in a TLS 1.3 only environment. The best approach would be for Microsoft customers to make a feature request through their support channel. Cheers, Andrei From: Yuhong Bao

Re: [TLS] Suspicious behaviour of TLS server implementations

On Thu, Sep 22, 2016 at 05:11:39AM +, Peter Gutmann wrote: > Martin Thomson writes: > > >The advantage with deploying a new protocol is that you can be strict. If, > >for example, all of the browsers implement TLS 1.3 and are strict, then > >Amazon won't be able

Re: [TLS] Suspicious behaviour of TLS server implementations

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann wrote: > > Martin Thomson writes: > >> The advantage with deploying a new protocol is that you can be strict. If, >> for example, all of the browsers implement TLS 1.3 and are strict, then >>

[TLS] Signature Algorithms Extension Clarification

Hi all, I need a clarification regarding the use of the signature algorithms. Reading Section 4.2.3. "Signature Algorithms" I got the impression that there is a new extension being defined called 'supported_signature_algorithms', which replaces the previous 'signature_algorithm' extension.

[TLS] Industry Concerns about TLS 1.3

To: IETF TLS 1.3 Working Group Members My name is Andrew Kennedy and I work at BITS, the technology policy division of the Financial Services Roundtable (http://www.fsroundtable.org/bits). My organization represents approximately 100 of the top 150 US-based financial services companies

Re: [TLS] Signature Algorithms Extension Clarification

On Thu, Sep 22, 2016 at 2:33 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > Hi all, > > I need a clarification regarding the use of the signature algorithms. > > Reading Section 4.2.3. "Signature Algorithms" I got the impression that > there is a new extension being defined called >

Re: [TLS] Suspicious behaviour of TLS server implementations

On Wednesday, 21 September 2016 15:53:33 CEST Peter Gutmann wrote: > Andreas Walz writes: > >Actually, I wasn't aware of the fact that the TLS 1.3 draft now explicitly > >addresses this in the Presentation Language section: > > > > "Peers which receive a message

Re: [TLS] Antw: Re: Antw: Re: Suspicious behaviour of TLS server implementations

> On Sep 22, 2016, at 8:18 AM, Andreas Walz > wrote: > > I see your point here. However, where would you draw the line between "I > can't" and "I don't want to"? Think of a cipher suites list with 3 bytes in a > ClientHello. You can still find one cipher suite

Re: [TLS] Industry Concerns about TLS 1.3

Hi Andrew, My view concerning your request: no. Rationale: We're trying to build a more secure internet. Meta-level comment: You're a bit late to the party. We're metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans. More exactly, we

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 10:19 AM, BITS Security wrote: > To: IETF TLS 1.3 Working Group Members > > My name is Andrew Kennedy and I work at BITS, the technology policy division > of the Financial Services Roundtable (http://www.fsroundtable.org/bits). My >

Re: [TLS] Industry Concerns about TLS 1.3

On Thu, Sep 22, 2016 at 1:19 PM, BITS Security < bitssecur...@fsroundtable.org> wrote: > Like many enterprises, financial institutions depend upon the ability to > decrypt TLS traffic to implement data loss protection, intrusion detection > and prevention, malware detection, packet capture and

Re: [TLS] Industry Concerns about TLS 1.3

+1 to what Kenny said. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Industry Concerns about TLS 1.3

Mandating forward secrecy for TLS 1.3+ has been a strong consensus of this working group, so there's no point in myself or any other contributors just mass-replying with a big "no" here. That said, there is one puzzling thing I'm curious about: On Thursday, September 22, 2016 01:19:48 pm BITS

Re: [TLS] Industry Concerns about TLS 1.3

Yuhong-Thank you for the response. Our thinking here is that enterprises who use content delivery networks will have the end-user session hidden from them. The session from the end user to the edge of the content delivery network will be a different session than the one from the enterprise

Re: [TLS] Industry Concerns about TLS 1.3

Hi, Andrew. Thank you for bringing these concerns to the list. I agree with Kenny that this is rather late, but it’s also true that I don’t think it would change the outcome of the consensus in this working group. The quest to mandate FS in TLS-using applications goes back longer than this

Re: [TLS] Industry Concerns about TLS 1.3

Adding Andrei Popov. From: BITS Security Sent: Thursday, September 22, 2016 1:13:45 PM To: Yuhong Bao; tls@ietf.org Subject: RE: Industry Concerns about TLS 1.3 Yuhong-Thank you for the response. Our thinking here is that