Re: [TLS] TLS Impact on Network Security draft updated

[Watson Ladd <[e-mail]>]

On Tue, Jul 23, 2019, 1:51 PM Flemming Andreasen <[e-mail]> wrote:

>
>
> On 7/23/19 2:35 PM, Watson Ladd wrote:
>
> This draft contains substantial omissions in section 3.
>
> Nothing in TLS 1.3 prevents scanning for servers and examining the
> certificates they present.
>
> Agreed, however there is no guarantee that the server will present the
> same certificate and other TLS parameters as it will for a particular
> client connection
>

True but for 99% (WAG) of setups this is driven by SNI and ciphersuite
which you see in the clear.

Nothing in TLS 1.3 prevents using reverse proxies to provide WAF
> functionality.
>
> Agreed however you need to terminate the TLS 1.3 connection at that WAF
>

That doesn't sound like a big difficulty especially given the WAF was
intercepting and decrypting before. What is the gain here? It's also more
secure: there is fun with headers that doesnt work if the WAF normalizes.

PCI-DSS compliance is not at odds with deploying TLS 1.3. In fact the
> citation to A2 is to a sun-setting of all pre TLS 1.2 versions for point of
> sale terminals. I really don't see where the conflict exists since all
> ciphers in 1.3 are secure.
>
> I'll defer to one of my co-authors on this one.
>
> The absence of these solutions means the draft overstates the impact of
> the increased protection TLS 1.3 provides. It's disappointing to see
> sustained and persistent opposition to encryption and privacy despite
> multiple RFCs saying that yes we should encrypt all the things.
>
> The draft is submitted with the intent of informing the community about
> impacts as we see them. The authors welcome discussion and constructive
> feedback and we will be happy to update and improve the draft accordingly
> when such information is provided and consensus forms around it. Specific
> text suggestions will be even better.
>

I seem to remember a discussion during the last call of TLS 1.3 where these
issues were raised. I think at minimum pointing out that this only affects
some networks with some choices of how to do things and that other
techniques (like reverse proxies) can achieve the same ends is necessary if
the goal is actually to help operators cope with TLS 1.3.


> Thanks
>
> -- Flemming
>
>
> On Tue, Jul 23, 2019, 8:08 AM Bret Jordan <[e-mail]> wrote:
>
>> Nancy,
>>
>> I support this work and think this draft should be published. This is a
>> yet another good write up on some of the requirements that are needed for
>> operational security.
>>
>> Thanks,
>> Bret
>> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
>> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that
>> can not be unscrambled is an egg."
>>
>> On Jul 21, 2019, at 9:51 AM, Nancy Cam-Winget (ncamwing) <
>> [e-mail]> wrote:
>>
>> Hi,
>> Thanks to all the feedback provided, we have updated the
>> https://tools.ietf.org/html/draft-camwinget-tls-use-cases-04
>> draft.  At this point, we believe the draft is stable and would like to
>> request its publication as an informational draft.
>>
>> Warm regards,
>>     Nancy
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
> _______________________________________________
> TLS mailing [e-mail]://www.ietf.org/mailman/listinfo/tls
>
>
>