Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> On Jul 12, 2017, at 7:11 PM, yinxinxing wrote: > > Thanks Wing, > > Please see my comments inline. > > Regards, > Yin Xinxing > > -邮件原件- > 发件人: Dan Wing [mailto:danw...@gmail.com] > 发送时间: 2017年7月13日 8:52 > 收件人: yinxinxing > 抄送: tls@ietf.org; Sean Turner > 主题: Re: [TLS] Solving the

[TLS] 答复: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

Thanks Wing, Please see my comments inline. Regards, Yin Xinxing -邮件原件- 发件人: Dan Wing [mailto:danw...@gmail.com] 发送时间: 2017年7月13日 8:52 收件人: yinxinxing 抄送: tls@ietf.org; Sean Turner 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in

[TLS] 答复: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

Thanks Sean! Your question and comments are valuable. Please check my comments inline. Regards, Yin Xinxing -邮件原件- 发件人: Sean Turner [mailto:s...@sn3rd.com] 发送时间: 2017年7月12日 22:57 收件人: yinxinxing 抄送: tls@ietf.org 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> On Jul 12, 2017, at 5:21 PM, yinxinxing wrote: > > Hi Dan Wing, > > Thanks for your comments. > > Please see my comments inline. > > Regards, > Yin Xinxing > > -邮件原件- > 发件人: Dan Wing [mailto:danw...@gmail.com] > 发送时间: 2017年7月13日 1:09 > 收件人: yinxinxing > 抄送: tls@ietf.org; Sean Turn

[TLS] 答复: Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

Hi Dan Wing, Thanks for your comments. Please see my comments inline. Regards, Yin Xinxing -邮件原件- 发件人: Dan Wing [mailto:danw...@gmail.com] 发送时间: 2017年7月13日 1:09 收件人: yinxinxing 抄送: tls@ietf.org; Sean Turner 主题: Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with

Re: [TLS] 2nd WGLC: draft-ietf-tls-tls13

On 07/11/2017 03:50 PM, Eric Rescorla wrote: > > > On Tue, Jul 11, 2017 at 1:39 PM, Benjamin Kaduk > wrote: > > > Another question I also relates to 0-RTT, specifically with the > freshness checks and the case where the computed > expected_arrival_time is in o

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 12/07/17 21:01, Kathleen Moriarty wrote: > With no hat on... > > The difference with the WordPress & SMTP examples is that you know > content will sit in plaintext on the servers, whereas with POTS, you > need to wiretap to get the voice content. You only expect the log > that the call transp

Re: [TLS] chairs - please shutdown wiretapping discussion...

With no hat on... Sent from my iPhone > On Jul 12, 2017, at 6:18 PM, Stephen Farrell > wrote: > > > >> On 12/07/17 16:54, Kyle Rose wrote: >> On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell >> wrote: >> >>> >>> On 12/07/17 16:27, Kyle Rose wrote: The telco in the POTS case isn

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> On Jul 12, 2017, at 7:56 AM, Sean Turner wrote: > > >> On Jul 6, 2017, at 23:04, yinxinxing wrote: >> >> Hi all, >> >> The NAT table expiring problem mentioned in the following email should also >> be considered in DTLS1.2 as an extension. >> >> The value and necessity are as follows. >

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 12/07/17 16:54, Kyle Rose wrote: > On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell > wrote: > >> >> >> On 12/07/17 16:27, Kyle Rose wrote: >>> The telco in the POTS case isn't either endpoint. The third-party >>> surveillance is unknown to those endpoints. Therefore: wiretapping. >> >> Same

Re: [TLS] TLS Digest, Vol 156, Issue 65

I agree that all political aspects should not be part of TLS WG discussions. TLS 1.3 is supposed to increase users(that include not only end point users but all the "evil" service providers, enterprises , ..)) security and privacy but not to avoid legal court of law judgments for private compa

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 11:28 AM, Stephen Farrell wrote: > > > On 12/07/17 16:27, Kyle Rose wrote: > > The telco in the POTS case isn't either endpoint. The third-party > > surveillance is unknown to those endpoints. Therefore: wiretapping. > > Same in the wordpress.com or smtp/tls cases already

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 12/07/17 16:27, Kyle Rose wrote: > The telco in the POTS case isn't either endpoint. The third-party > surveillance is unknown to those endpoints. Therefore: wiretapping. Same in the wordpress.com or smtp/tls cases already described on list. Therefore: wiretapping. My point was that "collabo

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell wrote: > > If one endpoint is feeding > > cryptographic material to a third party (the only way that information > gets > > out to the third party, vulnerabilities notwithstanding), they are > > collaborating, not enabling wiretapping. > > That's

Re: [TLS] chairs - please shutdown wiretapping discussion...

On 12/07/17 13:24, Kyle Rose wrote: > This proposal (and related proposals involving encrypting session keys to > inspection boxes, either in-band or OOB) violates condition 2 because one > endpoint would have to intentionally take action to deliver the session key > or private DH share to the th

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Tue, Jul 11, 2017 at 01:54:40PM -0700, Christian Huitema wrote: > On 7/11/2017 1:31 PM, Stephen Farrell wrote: > > > PS: There are also genuine performance reasons why the same > > DH public might be re-used in some cases, so there would be > > false positives in a survey to consider as well. >

Re: [TLS] Solving the NAT expiring problem causing DTLS renegotiation with high power consumption in DTLS1.2

> On Jul 6, 2017, at 23:04, yinxinxing wrote: > > Hi all, > > The NAT table expiring problem mentioned in the following email should also > be considered in DTLS1.2 as an extension. > > The value and necessity are as follows. > > 1. Essentially, NAT expiring problem causing DTLS renegot

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > > Oh, come on. You've never seen code in a library that implements > something that's not in an IETF RFC? > > > Of course I have. I think that putting a warning in the TLS 1.3 spec as >

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:35 AM, Kyle Rose wrote: > Which will have zero impact on pervasive surveillance until some government > decides they want to use this mechanism or something like it and mandates > that it be implemented universally within their borders. Then it will appear > in short orde

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:32 AM, Richard Barnes wrote: > Oh, come on. You've never seen code in a library that implements something > that's not in an IETF RFC? Of course I have. I think that putting a warning in the TLS 1.3 spec as Christian suggested will mean that the code won't appear in

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena w

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 10:22 AM, Ted Lemon wrote: > On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena w

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 10:18 AM, Kyle Rose wrote: > We need to dispel the myth that mere inaction on our part will on its own > prevent implementation of these mechanisms, if for no other reason but to > redirect energy to the political arena where the pervasive monitoring battles > *are* actually

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Wed, Jul 12, 2017 at 8:57 AM, Ted Lemon wrote: > The problem is that in modern times we can't assume that collaboration is > consensual, so the rules in RFC2804 aren't as applicable as they were. > Until someone comes up with a technical countermeasure for involuntary collusion, the solution

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Jul 12, 2017, at 8:24 AM, Kyle Rose wrote: > Much of this conversation seems to conflate wiretapping with collaboration. > 2804 has a clear definition of wiretapping: The problem is that in modern times we can't assume that collaboration is consensual, so the rules in RFC2804 aren't as appli

Re: [TLS] chairs - please shutdown wiretapping discussion...

On Tue, Jul 11, 2017 at 9:11 AM, Ted Lemon wrote: > It’s also true that you can just exfiltrate every key as it’s generated, > but that’s not what’s being proposed and would not, I think, suit the needs > of the operators who are making this proposal. > > I don’t see how you could mitigate agains

Re: [TLS] chairs - please shutdown wiretapping discussion...

Bill, I agree that we need to find the "least bad" option, if for no other reason than to prove there is no acceptable solution. If I may, I'd like to suggest another possible way to get to "least bad". Perhaps our goal should not be to prevent servers collaborating with the monitoring, which