Re: [TLS] Connection ID Draft

2017-10-25 Thread Eric Rescorla
On Wed, Oct 25, 2017 at 8:02 PM, yinxinxing wrote: > Hi Ekr, > > > > Sorry for the delay. I don’t quite understand “The way that this > mechanism works is that it either replaces all of them or supplements the > set.” I see the new CID is encrypted in the post-handshake

Re: [TLS] Connection ID Draft

2017-10-25 Thread yinxinxing
Hi Ekr, Sorry for the delay. I don’t quite understand “The way that this mechanism works is that it either replaces all of them or supplements the set.” I see the new CID is encrypted in the post-handshake message and transferred to the peer. So, the record header of this message needs to

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Salz, Rich
➢ options (quoted below) are wrong or do not work. The objection is that the IETF should not be publishing a RFC that documents them, is that right? Not at all. But maybe I’m mistaken; do you have links to messages that said that? The draft in the subject line is a different item

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Stephen Farrell
On 25/10/17 23:58, Peter Bowen wrote: > So, to be completely clear, no one is arguing that Nick's three > options (quoted below) are wrong or do not work. The objection is > that the IETF should not be publishing a RFC that documents them, is > that right? No, it's not that simple. For

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Peter Bowen
On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell wrote: > > > On 25/10/17 23:37, Richard Barnes wrote: >> Sorry, what? The current draft proposes an extension, literally the >> opposite of a standard, supported feature. It's explicitly optional. > > Optional is not

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Stephen Farrell
On 25/10/17 23:37, Richard Barnes wrote: > Sorry, what? The current draft proposes an extension, literally the > opposite of a standard, supported feature. It's explicitly optional. Optional is not the opposite of standard. See the intended status below. > I don't really have a dog in this

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Richard Barnes
On Oct 25, 2017 22:34, "Stephen Farrell" wrote: Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Stephen Farrell
On 25/10/17 17:11, Ackermann, Michael wrote: > And if this is not a feature that everyone wants, then so be it. > But at least it was an attempt by a small number of people to try to > find common ground and make any form of progress. I do not accept that there is an onus on IETF participants

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Stephen Farrell
Replying to just a couple of bits... On 25/10/17 15:23, David A. Cooper wrote: > Similarly, the best that TLS can offer in terms of privacy is that the > contents of the communication between the two endpoints is not seen by > anyone else *unless* at least one of the two endpoints (client or >

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Ted Lemon
On Oct 25, 2017, at 3:34 PM, Nick Sullivan wrote: > Forward secrecy with respect to other keys, like the session ticket key or > other keys that can be generated centrally, are things that need to be looked > at more closely for TLS 1.4 (or whatever’s next). Unless

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Nick Sullivan
I didn't want to stick my foot in this, but here we are. The goal for an inspection service to be able to take a recording of the network and a key (or corpus of keys) and be able to decrypt any TLS connection to a server within that network. There are multiple ways of getting these keys. 1) use

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Jeffrey Walton
On Wed, Oct 25, 2017 at 12:21 PM, Roland Zink wrote: > It could but RFC 7469 section 2.6 > (https://tools.ietf.org/html/rfc7469#section-2.6) says: > > " It is acceptable to allow Pin >Validation to be disabled for some Hosts according to local policy. >For example, a UA

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread David A. Cooper
No, they would not prevent those other mechanisms. Where is your evidence that they would? If the "attacker" controls the software that the client is using, then it would set up the software to not check public-key pinning or CT, if necessary. As Richard

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Roland Zink
It could but RFC 7469 section 2.6 (https://tools.ietf.org/html/rfc7469#section-2.6) says: " It is acceptable to allow Pin Validation to be disabled for some Hosts according to local policy. For example, a UA may disable Pin Validation for Pinned Hosts whose validated certificate

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Richard Barnes
On Wed, Oct 25, 2017 at 12:06 PM, Salz, Rich wrote: > > since those other means would be easier and more effective. You > have done nothing to suggest otherwise. > > Public-key pinning and CT seem like they would prevent those other > mechanisms. No? > Remember that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Ackermann, Michael
" idea of a client extension was added based on feedback at the Prague meeting in order to help prevent the protocol from being used over the public Internet, by preventing the protocol from being used without the client's knowledge." Responding ONLY to the above sentence, as I agree with

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Salz, Rich
> since those other means would be easier and more effective. You have done nothing to suggest otherwise. Public-key pinning and CT seem like they would prevent those other mechanisms. No? ___ TLS mailing list TLS@ietf.org

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread David A. Cooper
I've already responded to this! Why are you wasting everyone's time by asking the same questions over and over, even though I've already clearly answered them? An airplane/wifi provider might say "download our free browser," but it won't rely on draft-rhrd-tls-tls13-visibility to snoop on its

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Salz, Rich
>This question is based on your that belief that this protocol will > "escape" onto the public Internet Yes. Are you saying that you don’t believe that the enterprise visibility will stop at their firewall? That they will allow ‘stock’ TLS 1.3 to work connecting to their sites? That the

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread David A. Cooper
This question is based on your that belief that this protocol will "escape" onto the public Internet, that browsers and other clients used by individuals will feel forced to implement it, and that clients will then be forced to enable the extension in order to get through middleboxes that

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Salz, Rich
➢ Similarly, the best that TLS can offer in terms of privacy is that the contents of the communication between the two endpoints is not seen by anyone else *unless* at least one of the two endpoints (client or server) chooses to provide the contents of the communication to some

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread David A. Cooper
Everything I have stated is my personal opinion. Note that I never suggested that I like or am espousing a certain approach, I was simply stating a fact. In many cases today, a TLS connect that appears to a client to be terminating a one place (Company X) is actually terminating somewhere

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

2017-10-25 Thread Salz, Rich
Before you leave, there are a number of questions still unanswered. 1 Can this draft enable an active attacker to modify traffic? If not, then then how is that prevented? 2 Can this draft be used to segregate traffic so that only those willing to be intercepted can be handled separately from

Re: [TLS] DTLS 1.3 ACKs

2017-10-25 Thread Ilari Liusvaara
On Wed, Oct 25, 2017 at 08:48:56AM +0200, Nikos Mavrogiannopoulos wrote: > On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > > > The one thing we ran into was the potential need to ACK in cases > > where you > >

Re: [TLS] DTLS 1.3 ACKs

2017-10-25 Thread Nikos Mavrogiannopoulos
On Mon, 2017-10-23 at 18:14 -0700, Eric Rescorla wrote: > We now have DTLS 1.3 implemented in NSS, which went pretty cleanly. > > The one thing we ran into was the potential need to ACK in cases > where you > can't process *any* records (e.g., you receive what's actually EE, > but you > can't