Hi Peter,
too bad that you are not attending the upcoming IETF meeting in person.
I am sure that others would like to hear your thoughts about an
end-to-end security solution that is even better than the TLS 1.3
protocol. At least I am interested.
Maybe you can share something on the list.
Ciao
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 Wed
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 t
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 certificate”
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 to the cloud uses HTTPS. The communication
from the BLE
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 p
From: Ben Schwartz [mailto:bem...@google.com]
Sent: Tuesday 31 October 2017 21:17
To: Owen Friel (ofriel)
Cc: Richard Barnes ;
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
On Tue, Oct 31, 2017 at 5:03 PM, Owen Friel (ofriel)
mailto:ofr...@cisco.com
Some feedback, in no particular order:
* have a hard think about handshake/termination loads. istm this scheme
devolves pretty quickly to a termination per object HTTP/1.0 style so
you'll be fairly quickly looking to do some kind of multiplexing and reuse
on top of it for the same reasons HTTP evo
Hi Owen,
On 31/10/17 21:03, Owen Friel (ofriel) wrote:
>> Interesting. One bit puzzles me: wouldn't the new content-type
>> give the game away and cause middleboxes to block this?
>>
>> S.
>>
> [ofriel] The intention isn’t to try and obscure the fact that there
> is an ATLS session. Even if th
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
> Sent: 30 October 2017 22:56
> To: Richard Barnes ;
> Subject: Re: [TLS] New Version Notification for
> draft-friel-tls-over-http-00.txt
>
>
>
> On 30/10/
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ben Schwartz
Sent: 31 October 2017 01:35
To: Richard Barnes
Cc:
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes
mailto:r...@ipv.sx>> wrote:
It re
On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes wrote:
> It requires awareness in the following sense: If by chance the client is
> in a nice, open network and the base TLS connection goes directly to the
> server, CONNECT is kind of unnatural; you would want the client to do
> something differen
Please consult with the HTTP WG *before* you start work in this area.
Thanks,
> On 31 Oct 2017, at 9:17 am, Richard Barnes wrote:
>
> Hey TLS folks,
>
> Owen, Max, and I have been kicking around some ideas for how to make secure
> connections in environments where HTTPS is subject to MitM /
It requires awareness in the following sense: If by chance the client is in
a nice, open network and the base TLS connection goes directly to the
server, CONNECT is kind of unnatural; you would want the client to do
something different in that case. You're correct that you *could*
configure the se
On 30/10/17 22:17, Richard Barnes wrote:
> Hey TLS folks,
>
> Owen, Max, and I have been kicking around some ideas for how to make secure
> connections in environments where HTTPS is subject to MitM / proxying.
Interesting. One bit puzzles me: wouldn't the new content-type
give the game away an
But I agree, it would be good to have some more clarity around use cases
and why not other solutions.
On Mon, Oct 30, 2017 at 6:37 PM, Richard Barnes wrote:
> HTTP CONNECT is not great for some use cases because it requires the app
> to be aware that it's dealing with a proxy. It's simpler if y
HTTP CONNECT is not great for some use cases because it requires the app to
be aware that it's dealing with a proxy. It's simpler if you can just have
one code path that works whether your TLS is intermediated or not. With
the solution outlined in the draft, you can just always ignore the
certifi
Hey TLS folks,
Owen, Max, and I have been kicking around some ideas for how to make secure
connections in environments where HTTPS is subject to MitM / proxying.
The below draft lays out a way to tunnel TLS over HTTPS, in hopes of
creating a channel you could use when you really need things to be
18 matches
Mail list logo
