From: Jen Linkova
Sent: 28 July 2020 23:14
To: tom petch
On Wed, Jul 29, 2020 at 2:07 AM tom petch wrote:
>> This email starts the WG Last Call for draft-ietf-opsec-ns-impact ,
>> Impact of TLS 1.3 to Operational Network Security Practices,
>> https://datatracker.ietf.org/doc/draft-ietf-opsec-ns-
On Wed, Jul 29, 2020 at 6:41 PM tom petch wrote:
> Jen, it is more than that. I think that the IETF way of working is to make
> comments, get an acknowledgement and a response, from author, others, Chair,
> AD i.a., discuss the issues, accept or reject changes, new version, rinse and
> repeat.
The following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6244
--
Type: Editorial
Re
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
On 7/29/20 at 5:20 AM, furr...@gmail.com (Jen Linkova) wrote:
So issuing the WGLC in the trough between IETF meetings caused an
undesirable outcome of people not paying enough attention.
But thanks for the comments, I'll take it into account - let's
consider it my learning curve..
As a long-ti
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
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 to
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 Ben,
Thanks for your comments. Please find some responses inline.
On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz < bem...@google.com > wrote:
>
> This proposal is highly ossifying. Application protocols that are
> included in this scheme become very difficult to update. For example, in
> th
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, which
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
eavesd
> 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.
However
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 c
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 just
>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”
arg
On Wed, Jul 29, 2020 at 4:51 PM Yiannis Yiakoumis <
yian...@selfienetworks.com> wrote:
> Hi Ben,
>
> Thanks for your comments. Please find some responses inline.
>
> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz wrote:
>
>> This proposal is highly ossifying. Application protocols that are
>> inc
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, p
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 e
18 matches
Mail list logo
