Re: [TLS] Industry Concerns about TLS 1.3

On 9/28/16 at 4:27 PM, melinda.sh...@nomountain.net (Melinda Shore) wrote: That said, IETF participation is dominated by large equipment and software vendors and the problem space, at least until recently (there's been a crop of data center-related problems coming up in OPS and routing), has

Re: [TLS] Industry Concerns about TLS 1.3

On Wed, Sep 28, 2016 at 5:49 PM, Melinda Shore wrote: > I think it's quite clearly the case that that is not going to happen. > But, that doesn't mean that these guys don't have a problem worth > addressing, even if they're asking for a crap solution to it. The >

Re: [TLS] Industry Concerns about TLS 1.3

On 9/28/16 4:36 PM, Tony Arcieri wrote: > The IETF is doing great work. This entire thread is a distraction, and I > hope it does not result in changes which weaken TLS 1.3's security. I think it's quite clearly the case that that is not going to happen. But, that doesn't mean that these guys

Re: [TLS] Industry Concerns about TLS 1.3

On Wed, Sep 28, 2016 at 4:27 PM, Melinda Shore wrote: > We have poor participation and representation from > enterprise networks. So now we've got someone showing up from > the enterprise space and saying "I have this problem related to > protocol changes." And

Re: [TLS] Industry Concerns about TLS 1.3

On 9/28/16 3:08 PM, Bill Frantz wrote: > On 9/28/16 at 2:01 AM, m...@sap.com wrote: >> I'm sorry, but I'm still violently opposed to the IETF endorsing >> backdooring of security protocols. > I find myself in violent agreement with Martin, and many others in the > IETF. This seems uncontroversial

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

Ø I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS. + 1 While I agree that the server should be using the server’s preferences in most cases, I see no reason for the client to not list protocol versions (and cipher suites, for that matter) in the

Re: [TLS] Industry Concerns about TLS 1.3

> On 28 Sep 2016, at 7:16 PM, Dan Brown wrote: > > As I understand the concern, the worry is that Bud is compromising Bob's > (TLS) server, to somehow send Bob's plaintext to the wrong place. > > The proposed (existing?) strategy has Bob compromising his own >

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

I don't really agree that we shouldn't specify client order. We do that everywhere else in TLS. Rather, I think we should relax the requirement to pick the highest one, which is just a holdover from a less expressive negotiation mechanism. -Ekr On Wed, Sep 28, 2016 at 9:18 AM, Stephen

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

On Wed, Sep 28, 2016 at 9:37 AM, Salz, Rich wrote: > On the crypto-library side, boringSSL had equivalence classes so you could > specify that by configuring the CIPHER list. If running in a server, and the > configured ciphers were like "[AES:CHACHA]:3DES:RC4" for example,

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

> C.2 Negotiating with an older client says, "If the >"supported_versions" extension is present, the server MUST negotiate >the highest server-supported version found in that extension." I agree that an appendix is the wrong place to put this. And that specifying the client order is

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

On 29 September 2016 at 02:02, Stephen Checkoway wrote: > * The only time to take the client's preference into account is if the server > really has no opinion on an option--e.g., two equivalent-strength cipher > suites--but the client can specify a preference for an option

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

> On Sep 22, 2016, at 6:42 PM, Eric Rescorla wrote: > > - New version negotiation format (*) [IMPORTANT: this got lost in the > ChangeLog] 4.2.1 Supported Versions says, "The extension contains a list of supported versions in preference order, with the most preferred

Re: [TLS] Industry Concerns about TLS 1.3

Martin Rex wrote: > Stephen Farrell wrote: > > > > On 28/09/16 01:17, Seth David Schoen wrote: > > > People with audit authority can then know all of the secrets, > > > > How well does that whole audit thing work in the financial services > > industry? (Sorry, couldn't resist:-) > > I am

Re: [TLS] Industry Concerns about TLS 1.3

Stephen Farrell wrote: > > On 28/09/16 01:17, Seth David Schoen wrote: > > People with audit authority can then know all of the secrets, > > How well does that whole audit thing work in the financial services > industry? (Sorry, couldn't resist:-) I am actually having serious doubts that it

Re: [TLS] Industry Concerns about TLS 1.3

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Aloha! Salz, Rich wrote: >> I understand your concern over what the nation-state actors are >> doing but it is not the same as what Enterprises do to manage their >> private servers, networks and clients. > > Okay, in technical terms only, what is

Re: [TLS] Industry Concerns about TLS 1.3

Judson Wilson wrote: > > I think this challenge is best solved by putting the information on the > wire in some way, possibly as a special industry-specific extension (used > only by those who are bent on shooting themselves in the foot). The benefit > being that if the TLS channel is alive, the

Re: [TLS] Industry Concerns about TLS 1.3

Hi Andrew, I am coming from a different industry, the embedded industry, and for us at ARM the development of TLS 1.3 will help us to increase the security of Internet of Things devices as well as to improve the performance of the handshake. We are reaching out to developers and our partners to

[TLS] How to contribute to TLS RFC

Hello, I have just joined a new company and have been asked to contribute to TLS RFC within two years. I request you to guide me how to go about it. What books etc will you recommend ? Please also advise if I should also join a TLS implementation group. If yes, which one ? Thanks and Regards,