the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> wrote:
>
>
> Folks,
>
>
>
> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
>
>
>
> Please send comments to op...@ietf.org by August
0 at 3:35 AM Ron Bonica
mailto:rbonica=40juniper@dmarc.ietf.org>>
wrote:
Folks,
This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
Please send comments to op...@ietf.org<mailto:op...@ietf.org>
On Tue, 28 Jul 2020 at 10:35, Arnaud.Taddei.IETF
wrote:
> I strongly support this work as it represents capabilities that are being
> developed, deployed and used in practice. It has good intentions and provides
> a good approach in the context of defense in depth approaches. No security
>
Peace,
On Thu, Jul 30, 2020, 4:39 PM Salz, Rich wrote:
> We have a product, site shield, that customers can use to limit the IP
> addresses of who can reach their origin server. Everyone else is blocked..
> Some use that to make sure that *only* Akamai servers will talk to them,
> and that
>In the majority of cases (i.e. delivering preseeded static content),
no. It identifies as some-1337-garbage.static.example.com, which it
basically *is*.
No. That might be the DNS name, but it is not the TLS certificate that the
server presents. That certificate MUST have a name
Peace,
On Thu, Jul 30, 2020 at 3:33 PM Salz, Rich wrote:
>> It is (in all but a couple of implementations I think)
> a *proxy* that the origin has contracted with. Could
> you please elaborate on your point?
>
> It has a TLS cert that identifies itself as the origin.
It depends!
In the
* It is (in all but a couple of implementations I think) a *proxy* that the
origin has contracted with. Could you please elaborate on your point?
It has a TLS cert that identifies itself as the origin. It doesn’t just
terminate TLS, but it does work at the HTTP layer.
How is it different
Peace,
On Wed, Jul 29, 2020, 2:20 PM Salz, Rich
wrote:
> Also, a CDN is not a proxy. It **IS** an entity that the origin has
> contracted with to perform certain functions.
>
It is (in all but a couple of implementations I think) a *proxy* that the
origin has contracted with. Could you
Peace,
On Mon, Jul 27, 2020, 4:18 PM Blumenthal, Uri - 0553 - MITLL
wrote:
> in this particular case, instead of "if you want to do this, then do it
> that way, and I'll help you inter-operate" I prefer "if you want to do this
> - you're on your own, don't seek a blessing or advice from me".
>
opsec-cha...@ietf.org>;
tls@ietf.org<mailto:tls@ietf.org>
Subject: Re: [TLS] [OPSEC] Call For Adoption: draft-wang-opsec-tls-proxy-bp
I strongly support this work as it represents capabilities that are being
developed, deployed and used in practice. It has good intentions and provides a
On Wed, Jul 29, 2020 at 9:48 PM Eric Wang (ejwang) wrote:
> To echo the ickiness part… Putting on my end user hat, if I have to take
> it with an enterprise device on the enterprise network, I would rather it
> be done securely, respecting my privacy... If I’m on my home network, I
> want an
To echo the ickiness part… Putting on my end user hat, if I have to take it
with an enterprise device on the enterprise network, I would rather it be done
securely, respecting my privacy... If I’m on my home network, I want an easy
way to detect and reject it, no matter it is from a vendor,
>I would say rather that those analyses consider them as protocol endpoints and
>address the two individual connections terminated by the proxy and have
>nothing to say about the composition of those two connections.
I think that some of those opposed are conflating the general “end to end”
On Wed, Jul 29, 2020 at 5:36 PM Eric Rescorla wrote:
> I'm by no means denying the fact that MITM boxen
>> are deployed, but the idea that some of them are
>> "conformant" and some are not seems bogus.
>>
>
> Well, they are either conformant with the text of 8446 S 9.3 or they are
> not (and
On Wed, Jul 29, 2020 at 5:06 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 30/07/2020 00:56, Eric Rescorla wrote:
> > What text in TLS do you believe terminating proxies (in either direction)
> > do not conform to?
>
> I gtend to start with the abstract: "TLS allows
> client/server applications to
> I gtend to start with the abstract: "TLS allows
> client/server applications to communicate over the
> Internet in a way that is designed to prevent
> eavesdropping, tampering, and message forgery."
It seems clear that TLS proxies obey the letter, if not the spirit, of that
statement.
Hiya,
On 30/07/2020 00:56, Eric Rescorla wrote:
> What text in TLS do you believe terminating proxies (in either direction)
> do not conform to?
I gtend to start with the abstract: "TLS allows
client/server applications to communicate over the
Internet in a way that is designed to prevent
On Wed, Jul 29, 2020 at 4:27 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 29/07/2020 23:46, Eric Wang (ejwang) wrote:
> > It was the motivation of this draft to help reduce/prevent
> > non-compliance, as mentioned earlier.
> TLS MITM products, by design, do not comply with the TLS
> protocol,
Hiya,
On 29/07/2020 23:46, Eric Wang (ejwang) wrote:
> It was the motivation of this draft to help reduce/prevent
> non-compliance, as mentioned earlier.
TLS MITM products, by design, do not comply with the TLS
protocol, which is a 2 party protocol.
There is *only* non-compliance in this space.
Hi Martin,
I understand your point.
When starting this document, we analyzed TLS proxy for 3 possibilities:
1. It may violate existing specs inevitably;
2. It can be compliant but needs development work for some new “helper”
protocol;
3. Neither #1 or #2, but it needs a set of requirements
It looks the “selective proxying” topic requires a full document to analyze it.
The co-authors discussed and it would be a good idea to remove it from this
draft. We will made the updates.
The concern is valid that "there's no guarantee that the server will respond to
the client the same way
Also, a CDN is not a proxy. It *IS* an entity that the origin has contracted
with to perform certain functions.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hi Eric,
On Wed, Jul 29, 2020, at 07:18, Eric Wang (ejwang) wrote:
> In any case, the proxy has to conduct selective proxying in a safe,
> non-disruptive manner.
I will try to be clearer on this point.
This requires design work and this document is a poor vehicle for that. It
needs a
e thing to add here: the chairs would like to hear active and
> explicit support of the adoption. So please speak up if you believe
> the draft is useful and the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> wrote:
to other ways to shape it.
More inline...
On Jul 28, 2020, at 12:25 AM, Martin Thomson
mailto:m...@lowentropy.net>> wrote:
On Mon, Jul 20, 2020, at 03:34, Ron Bonica wrote:
This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp
<https://datatracker.ietf.org/doc/draft-w
n Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
wrote:
>
> Folks,
>
>
>
> This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
>
>
>
> Please send comm
upport of the adoption. So please speak up if you believe
> the draft is useful and the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> rbonica=40juniper@dmarc.ietf.org wrote:
>
> > Folks,
> > This email begins a Call For Adoption on draft-wa
I agree with the proposed approach and I also believe in discussion around
safe and responsible middlebox deployment. I support the adoption of this
draft!
Regards
-Ashu
On Mon, Jul 27, 2020 at 7:45 PM Roelof duToit wrote:
> RFC 8446, section 9.3 states:
> *Note that TLS's protocol
RFC 8446, section 9.3 states:
Note that TLS's protocol requirements and security analysis only
apply to the two connections separately. Safely deploying a TLS
terminator requires additional security considerations which are
beyond the scope of this document.
The context of that paragraph is "A
On 28/07/2020 00:48, Eric Wang (ejwang) wrote:
> We felt the lack of a
> baseline bcp is going to hurt the security posture of TLS rather than
> driving the intermediary away.
That makes no sense to me.
Adopting this draft will require eliminating all such
gibberish and instead finding text
Thanks you Rich. Obviously I support the adoption as one of the authors. But
more importantly, the reality of growing TLS proxy was the driver for starting
the draft. That has been a sidecar with the progression of TLS and its wide
deployment. We felt the lack of a baseline bcp is going to
ished.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
>
mailto:40juniper@dmarc.ietf.org>>
wrote:
>>
>> Folks,
>>
>>
>>
>> This email begins a Call For Adoption on
draft-w
published.
> >
> > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> > <mailto:40juniper@dmarc.ietf.org>> wrote:
> >>
As my personal opinion - both.
On 7/27/20, 10:22, "TLS on behalf of Salz, Rich" wrote:
>Understood. However, in this particular case, instead of "if you want
to do this, then do it that way, and I'll help you inter-operate" I prefer "if
you want to do this - you're on your own,
>Understood. However, in this particular case, instead of "if you want to
> do this, then do it that way, and I'll help you inter-operate" I prefer "if
> you want to do this - you're on your own, don't seek a blessing or advice
> from me".
So you don't feel that community is welcome here
>
>> S.
>>
>> On 23/07/2020 02:30, Jen Linkova wrote:
>> > One thing to add here: the chairs would like to hear active and
>> > explicit support of the adoption. So please speak up if you
>> believe
>> > the draf
> the draft is useful and the WG shall work on getting it published.
>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> wrote:
>>
>> Folks,
>>
>>
> On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> wrote:
>>
>> Folks,
>>
>>
>>
>> This email begins a Call For Adoption on
draft-wang-opsec-tls-proxy-bp.
>>
&
Hi Rich,
On 27/07/2020 13:37, Salz, Rich wrote:
> Not adopting this seems to be ignoring reality.
That depends on the "this" though. This "this" seems
to me to be very much ok with mitm'ing, while doing
a little bit to recognise the downsides of mitm'ing.
I'm not objecting to attempts to
Not adopting this seems to be ignoring reality. There are places which use TLS
intermediaries. Are those users not welcome here?
I support adoption.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
o hear active and
> > explicit support of the adoption. So please speak up if you believe
> > the draft is useful and the WG shall work on getting it published.
> >
> > On Mon, Jul 20, 2020 at 3:35 AM Ron Bonica
> > wrote:
> >>
lks,
This email begins a Call For Adoption on draft-wang-opsec-tls-proxy-bp.
Please send comments to op...@ietf.org<mailto:op...@ietf.org> by August 3, 2020.
Ron
Juniper Business Use Only
___
42 matches
Mail list logo
