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

["Eydlin, Igor - PENNINGTON NJ" <[e-mail]>]

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 companies to provide information to law enforcement. That will be done without utilizing "wiretapping". 


Thank you,
Igor Eydlin



-----Original Message-----
From: TLS [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Wednesday, July 12, 2017 11:27 AM
To: [e-mail]
Subject: TLS Digest, Vol 156, Issue 65

Send TLS mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= 
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."


Today's Topics:

   1. Re:  chairs - please shutdown wiretapping discussion...
      (Kyle Rose)
   2. Re:  Solving the NAT expiring problem causing DTLS
      renegotiation with high power consumption in DTLS1.2 (Sean Turner)
   3. Re:  chairs - please shutdown wiretapping discussion...
      (Ilari Liusvaara)
   4. Re:  chairs - please shutdown wiretapping discussion...
      (Stephen Farrell)
   5. Re:  chairs - please shutdown wiretapping discussion...
      (Kyle Rose)


----------------------------------------------------------------------

Message: 1
Date: Wed, 12 Jul 2017 10:45:18 -0400
From: Kyle Rose <[e-mail]>
To: Ted Lemon <[e-mail]>
Cc: Richard Barnes <[e-mail]>, IETF TLS <[e-mail]>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
Message-ID:
	<CAJU8_nXSru1oqPK=[e-mail]>
Content-Type: text/plain; charset="utf-8"

On Wed, Jul 12, 2017 at 10:38 AM, Ted Lemon <[e-mail]> wrote:

> On Jul 12, 2017, at 10:32 AM, Richard Barnes <[e-mail]> 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 places where
> there isn't a strong use case for it.   It may well appear in places where
> there is a strong use case, but anything open source is going to face a
> stiff headwind in terms of implementing this, and that's what I'm
> suggesting we encourage.   If it doesn't show up in openssl, gnutls or
> boringssl, it's a much smaller problem.   We can't actually stop it
> happening?I'm just arguing for not making it convenient.
>

Knowing the people involved in at least some of those projects, there is
very little chance of that happening. Beyond that lies political action,
which is definitely not what the TLS WG mailing list should be used for.

To your last email, I agree that we've mostly beaten this to death. I'm
happy to let the conversation move elsewhere.

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170712_f2bfb2e1_attachment.html&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=IzYzSB_05SZF60vhnl8tOo9a_5VJDJShAc4LPnzXyFY&e= >

------------------------------

Message: 2
Date: Wed, 12 Jul 2017 10:56:32 -0400
From: Sean Turner <[e-mail]>
To: yinxinxing <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: [TLS] Solving the NAT expiring problem causing DTLS
	renegotiation with high power consumption in DTLS1.2
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8

 
> On Jul 6, 2017, at 23:04, yinxinxing <[e-mail]> 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 renegotiation with high power consumption is existing in DTLS 1.2. Even if we solve this in DTLS1.3, this problem still exist for products using DTLS1.2.
> Currently, many IOT products using DTLS 1.2 are going to be deployed commercially, such as intelligent water/gas meter. These meters usually have limited battery and low cost. To be more accurate, the battery of the chip module of the intelligent water/gas meter are required to last for 10 years. These lead to an exercise strict control over the power consumption of the chip module. NAT expiring problem causing DTLS renegotiation with high power consumption is a bottleneck of these IOT devices. According to our experimental data, under the worst coverage level (ECL2), power consumption of the chip module when DTLS is embedded increases by nearly 60%. Therefore, there should be a solution to solve the urgent problem to match the low-cost and low-battery feature of the IOT devices in DTLS 1.2.

I have to ask whether these IoT devices are updatable?

> 2. DTLS 1.3 will be standardized in 2018, but the corresponding open source code will be available about one year later after the standardization. At present, large-scale commercial IOT industry deployment is urgent, it is too late to wait for DTLS 1.3. Thus, we hope that the above problem could be solved in DTLS 1.2 as soon as possible.

On this point, I?m hoping that you?ll be wrong ;). From the list of TLS implementations found here:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_wiki_Implementations&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=6XdEipZFd5sHWy_5fW04oKE1b36o_YKc-yZqp2ky4BA&e= 
and assuming there is as much enthusiasm to implement DTLS1.3 as there was for TLS1.3 then I?m hoping that the DTLS implementations will be ready much sooner than a year after publication (they might be ready before the RFC is published).

spt

> Any comment is appreciated.
>  
> Regards,
> Yin Xinxing
>  
>  
> ???: yinxinxing 
> ????: 2017?6?27? 16:28
> ???: 'Eric Rescorla'
> ??: [e-mail]; Tobias Gondrom
> ??: Re: [TLS] Yin Xinxing joins the TLS WG
>  
> Thanks Eric,
>  
> I have seen the CID scheme, and talked with Hannes(the author of the scheme).
>  
> CID scheme is a good idea to solve the problem I mentioned.
>  
> I think the length of CID (currently, it is 32 bits) can be longer so that it can support more DTLS sessions. It is known that for IOT scenario, 1 million connection is nothing.
>  
> Regards,
> Yin Xinxing
>  
> ???: Eric Rescorla [mailto:[e-mail]] 
> ????: 2017?6?25? 21:33
> ???: yinxinxing
> ??: [e-mail]; Xiongxiaochun
> ??: Re: [TLS] Yin Xinxing joins the TLS WG
>  
> Hi Yin,
>  
> The usual solution to this is to add a connection id. Please see:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_dtls13-2Dspec_issues_6&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=5YWOYG8tcG7o_991Mf2zy24y1TW9TAfAtwFpcdh5Juo&e= 
>  
> -Ekr
>  
>  
>  
>  
> On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing <[e-mail]> wrote:
> Hello everyone,
>  
> I am Yin Xinxing from Huawei company. I am glad to join the TLS WG.
>  
> For the DLTS 1.3 draft, I am interested and have some ideas to talk with you.
>  
> DTLS has a lot of application scenarios in IOT fields, but currently, there is some difficulty when DTLS 1.2 is applied to IOT devices, especially the battery-constrained IOT devices.
>  
> For example, when the IOT device wakes up from sleep mode, the NAT table may have expired.
> Then the IOT device has to establish a new DTLS session or at least launches a resume process with the server, the corresponding power consumption is too high for some power-constrained devices. 
> How can DTLS renegotiation be avoided in order to save battery?
>  
> I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem and give a proper solution.  
>  
> Any comment or idea about this problem is welcome.
>  
> Regards,
> Yin Xinxing
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= 
> 
>  
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= 



------------------------------

Message: 3
Date: Wed, 12 Jul 2017 18:08:31 +0300
From: Ilari Liusvaara <[e-mail]>
To: Christian Huitema <[e-mail]>
Cc: Stephen Farrell <[e-mail]>, Ted Lemon
	<[e-mail]>, [e-mail]
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
Message-ID: <20170712150831.xdq2byvjxlkbf2p3@LK-Perkele-VII>
Content-Type: text/plain; charset=utf-8

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.
> 
> Well, yes. The classic argument is performance. Saving the cost of
> exponentiation, computing G^X once for many session instead of once per
> session. But you reap most of the benefits of that optimization with a
> fairly small number of repetitions. Performance alone is not a good
> reason to use the key over extended period, not to share the exact same
> key between all servers in a farm. The fact is that wide reuse of the
> same (EC)DH private key does compromise the security of TLS -- including
> an obvious issue with forward secrecy.

Yes, the cost saturates very rapidly as the number of reuses increases.
Even 100 reuses gets one within ~1% of asymptotic limit (half load).

> In any case, I just submitted PR #1049
> (https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_1049&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=YkJeOlVlo3Qx-uAKThkyEZUyfHt71R_O2sqFEKkVVK0&e= ).

I didn't see this document the attack on integerity (full MITM attack)
of the connection if attacker has aquired the DH share before the
connection.


-Ilari



------------------------------

Message: 4
Date: Wed, 12 Jul 2017 16:18:23 +0100
From: Stephen Farrell <[e-mail]>
To: Kyle Rose <[e-mail]>, Ted Lemon <[e-mail]>
Cc: "Polk, Tim (Fed)" <[e-mail]>, IETF TLS <[e-mail]>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"



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 third party.

I agree if there are only two parties, i.e. some deployments
of schemes like this wiretapping scheme, do not meet the
definition of wiretapping in 2804.

> 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 nonsense. In the POTS case, telcos are collaborating
with their local LEAs and that is wiretapping. Claiming that
no deployment of this scheme (e.g. the SMTP or wordpress.com
type ones already described on the list) meets the 2804
definition is just silly.

S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170712_6da3397c_attachment.asc&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=UNyT2rSbelSxMPTijDbgVYicAe4PjUQY5-7DOPR9O8k&e= >

------------------------------

Message: 5
Date: Wed, 12 Jul 2017 11:27:09 -0400
From: Kyle Rose <[e-mail]>
To: Stephen Farrell <[e-mail]>
Cc: Ted Lemon <[e-mail]>, "Polk, Tim (Fed)"
	<[e-mail]>, IETF TLS <[e-mail]>
Subject: Re: [TLS] chairs - please shutdown wiretapping discussion...
Message-ID:
	<[e-mail]>
Content-Type: text/plain; charset="utf-8"

On Wed, Jul 12, 2017 at 11:18 AM, Stephen Farrell <[e-mail]
> 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 nonsense. In the POTS case, telcos are collaborating
> with their local LEAs and that is wiretapping.


The telco in the POTS case isn't either endpoint. The third-party
surveillance is unknown to those endpoints. Therefore: wiretapping.

Kyle
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_browse_tls_attachments_20170712_50ad2511_attachment.html&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=iD_LZ2XJ_0XYpIipM2JNOWusceuwCY4BhI-TZVbPais&e= >

------------------------------

Subject: Digest Footer

_______________________________________________
TLS mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwICAg&c=SFszdw3oxIkTvaP4xmzq_apLU3uL-3SxdAPNkldf__Q&r=Vz5mPTKmRh5XLwS5tp3D5gUo0x4x4r0IJ9DRWtVBuaA&m=DluIFkvB4756PmesQmSI7LNBIShUtsHbWRJDZAfN2ZM&s=eagfdAHLcUjsGrQuWbCquOnjlxa-xY34_J43XOpnCGg&e= 


------------------------------

End of TLS Digest, Vol 156, Issue 65
************************************

----------------------------------------------------------------------
This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer.   If you are not the intended recipient, please delete this message.