Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:25, Watson Ladd wrote: > > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> FWIW: In my experience middleboxes don't ossify based on what the spec says, >> they ossify based on what they see on the wire. So, if common >>

Re: [TLS] PR#1091: Changes to provide middlebox robustness

> On 8 Nov 2017, at 2:32, Salz, Rich wrote: > > ➢ Given that we're almost there, and that only really browsers are > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > >> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: >> > FWIW: In my experience middleboxes don't ossify based on what the spec

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 5:19 AM, Eric Rescorla wrote: > - The client sends a fake session_id and the server echoes it One friendly amendment. I think that we should insist (with a MUST) that the server send CCS in the case that it receives a non-empty session_id. That gives

Re: [TLS] network-based security solution use cases

Hiya, On 08/11/17 00:23, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > Please see below: > > On 11/7/17, 4:08 PM, "Stephen Farrell" wrote: > > > Hiya, > > On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > > Hi Stephen, Adding to

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote: > On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > > FWIW: In my experience middleboxes don't ossify based on what the spec > says, > > they ossify based on what they see on the wire. So, if common >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

➢ Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. The Internet is more than just a couple of browser

Re: [TLS] network-based security solution use cases

On Tue, Nov 7, 2017 at 4:23 PM, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, > Please see below: > > On 11/7/17, 4:08 PM, "Stephen Farrell" wrote: > > > Hiya, > > On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > > Hi Stephen,

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote: > FWIW: In my experience middleboxes don't ossify based on what the spec says, > they ossify based on what they see on the wire. So, if common > implementations send CCS in a particular way, that's what will get --- and, > I'll

Re: [TLS] network-based security solution use cases

Hi Stephen, Please see below: On 11/7/17, 4:08 PM, "Stephen Farrell" wrote: Hiya, On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, Adding to Flemming’s comment, finding “exact quotes” > will be difficult I'm

Re: [TLS] network-based security solution use cases

Hiya, On 07/11/17 23:53, Nancy Cam-Winget (ncamwing) wrote: > Hi Stephen, Adding to Flemming’s comment, finding “exact quotes” > will be difficult I'm sorry but when making a claim that such and such a regulation *requires* breaking TLS then you really do need to be that precise. > as their

Re: [TLS] network-based security solution use cases

Hiya, On 07/11/17 23:27, Flemming Andreasen wrote: > Thanks for taking an initial look at the document Stephen - please see > below for responses so far > > On 11/7/17 4:13 AM, Stephen Farrell wrote: >> Hiya, >> >> On 07/11/17 02:48, Flemming Andreasen wrote: >>> We didn't draw any particular

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 3:41 PM, Salz, Rich wrote: > ➢ Given that we're almost there, and that only really browsers are > asking for these hacks, and that even some of those were almost ready > to ship without these hacks, I don't think that this is entirely >

Re: [TLS] network-based security solution use cases

Hi Stephen, Adding to Flemming’s comment, finding “exact quotes” will be difficult as their intent is really not to break things but rather want to ensure that inspection and oversight is available to affect guards/protections within an (enterprise/data center) infrastructure. That said, PCI

Re: [TLS] PR#1091: Changes to provide middlebox robustness

➢ Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship without these hacks, I don't think that this is entirely unrealistic as an aspiration. The Internet is more than just a couple of

Re: [TLS] network-based security solution use cases

Thanks for taking an initial look at the document Stephen - please see below for responses so far On 11/7/17 4:13 AM, Stephen Farrell wrote: Hiya, On 07/11/17 02:48, Flemming Andreasen wrote: We didn't draw any particular line, but the use case scenarios that we tried to highlight are those

Re: [TLS] network-based security solution use cases

On 11/7/17 12:23 PM, Eric Rescorla wrote: On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen > wrote: Thank you for the feedback Ekr - please see below for responses On 11/6/17 12:43 PM, Eric Rescorla wrote: I took a look at

Re: [TLS] TLS Extensions: Omitting Handshake Messages

Okay, thank you very much, this clears it all up! Can I make a suggestion of making the section that describes the extension mechanism to mention that extensions can, in fact, choose to omit messages not marked as situation-depended/optional? Maybe this is already covered by the "it would be

Re: [TLS] TLS Extensions: Omitting Handshake Messages

Hi Illya, You are actually describing TLS 1.3, especially with recent (proposed) changes. It uses an extension to negotiate version, looking like TLS 1.2 otherwise. It has the ability to use lighter-weight algorithms, etc... On Wed, Nov 8, 2017 at 9:40 AM, Illya Gerasymchuk

Re: [TLS] TLS Extensions: Omitting Handshake Messages

On Tue, Nov 7, 2017 at 2:40 PM, Illya Gerasymchuk wrote: > Thank you very much for your answer. So just to be clear, hypothetically, > it would be possible to define an extension for TLS 1.2 that *converts > it to TLS 1.3 completely*, correct? > Well, this is effectively

Re: [TLS] TLS Extensions: Omitting Handshake Messages

Thank you very much for your answer. So just to be clear, hypothetically, it would be possible to define an extension for TLS 1.2 that *converts it to TLS 1.3 completely*, correct? For example, would it be possible, to have an extension called *TLS_1.2_TO_TLS_1.3 *that would define the full

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Wed, Nov 8, 2017 at 7:23 AM, Salz, Rich wrote: > “We can remove it when middleboxes aren’t a problem.” Talk about > aspirational ( Given that we're almost there, and that only really browsers are asking for these hacks, and that even some of those were almost ready to ship

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

If the embedded device is capable of running TLS anyway (e.g. fast enough to do RSA) why not have the phone act as a dumb proxy? However I see the draft has some additional scenarios where it makes sense, such as where the device must work with an off-the-shelf proxy that only speaks HTTP. On

Re: [TLS] PR#1091: Changes to provide middlebox robustness

I think Hubert makes excellent points. “We can remove it when middleboxes aren’t a problem.” Talk about aspirational ( ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 10:11 AM, Hubert Kario wrote: > On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > > In general +1, I like to see TLS 1.3 deployed ASAP and making the > spurious >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tuesday, 7 November 2017 18:17:33 CET Eric Rescorla wrote: > On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > > failures as rare as possible is a good way to make that happen. > > > > that

Re: [TLS] TLS Extensions: Omitting Handshake Messages

On Tue, Nov 7, 2017 at 6:15 AM, Illya Gerasymchuk wrote: > Greetings, > > I've been reading though various RFCs and couldn't find a definite answer > to my question: can a negotiated TLS extension skip some of the TLS > Handshake messages and still be compliant with the

[TLS] TLS Extensions: Omitting Handshake Messages

Greetings, I've been reading though various RFCs and couldn't find a definite answer to my question: can a negotiated TLS extension skip some of the TLS Handshake messages and still be compliant with the TLS specification? My goal is to develop a new version of TLS (as part of my Master Thesis

Re: [TLS] network-based security solution use cases

On Tue, Nov 7, 2017 at 7:56 AM, Flemming Andreasen wrote: > Thank you for the feedback Ekr - please see below for responses > > > On 11/6/17 12:43 PM, Eric Rescorla wrote: > > I took a look at this. > > Without getting into the question of whether the types of middleboxes >

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 7:39 AM, Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01

Re: [TLS] PR#1091: Changes to provide middlebox robustness

On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario wrote: > In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious > failures as rare as possible is a good way to make that happen. > > that being said, I have few comments: > > On Monday, 6 November 2017 19:19:01

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

On 11/7/17 8:15 AM, Hannes Tschofenig wrote: > FWIW: I can tell you what the threat model was with the layered TLS work. > > Let me give you a very specific example. Imagine a Bluetooth Low Energy > device that communicates via a phone to a cloud-based service. The > communication from the phone

Re: [TLS] network-based security solution use cases

Thank you for the feedback Ekr - please see below for responses On 11/6/17 12:43 PM, Eric Rescorla wrote: I took a look at this. Without getting into the question of whether the types of middleboxes you describe here provide a security benefit, there are several points in the document that are

Re: [TLS] PR#1091: Changes to provide middlebox robustness

In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious failures as rare as possible is a good way to make that happen. that being said, I have few comments: On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/1091 > > As I

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

Hi, Hannes. I think it makes sense if the middlebox (whether a TLS proxy or a phone) cannot perform a MitM attack against the internal TLS. This can be achieved by having separate trust anchors for the application vs the ones used for HTTPS, specifically not including any “proxy CA

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

On 11/07/2017 01:20 PM, Salz, Rich wrote: > > ➢ Our work was motivated by the discussions in the IoT groups about > re-inventing the TLS handshake at the application layer. > > Isn’t that what QUIC does (to a good enough approximation)? > I see QUIC more as a new transport

Re: [TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

➢ Our work was motivated by the discussions in the IoT groups about re-inventing the TLS handshake at the application layer. Isn’t that what QUIC does (to a good enough approximation)? ___ TLS mailing list TLS@ietf.org

[TLS] Layered TLS ... was Re: New Version Notification for draft-friel-tls-over-http-00.txt

This is interesting since Mark Baugher and myself have also been working on the use of TLS at the application layer and we did some implementation work with mbed TLS (with TLS 1.3) and OpenSSL. Our work was motivated by the discussions in the IoT groups about re-inventing the TLS handshake at the

Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt

What exactly is the threat model here? Are you trying to hide a connection from a reverse proxy at the server end? If so, the server operator should not have deployed a reverse proxy in the first place. Are you trying to hide from a MITM proxy that supplies its own certificate? If so, then what

Re: [TLS] network-based security solution use cases

Hiya, On 07/11/17 02:48, Flemming Andreasen wrote: >> > We didn't draw any particular line, but the use case scenarios that we > tried to highlight are those related to overall security and regulatory > requirements (including public sector) I had a quick look at the draft (will try read