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

[Mark O]

I don’t have a preference for whether this draft should become a working group 
item, or become an AD-sponsored or individual submission​, but in any case it 
contains important additions to the security considerations of RFC 8446. The 
use-cases it details are real-life scenarios where the introduction of TLS 1.3 
in place of 1.2 has an impact on the security of systems (according to the 
threat model outlined in RFC 3552 and the additional non-ComSec threats that 
have been identified subsequent to the publication of RFC 3552); therefore they 
should be accurately and publicly recorded.

-- Mark



On Sun, Jul 21, 2019 at 6:51 AM Nancy Cam-Winget (ncamwing) 
; 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

> TLS@ietf.org

> https://www.ietf.org/mailman/listinfo/tls






This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk. All material is UK Crown Copyright ©

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-sni-encryption

[Mark O]

Some comments on draft-ietf-tls-sni-encryption-03:

Section 2.3 "End-to-end alternatives"
"Enterprises can deploy monitoring software to control usage of the enterprises 
[sic] computers."
At the moment enterprises have the option of installing a firewall performing 
SNI filtering to black-list connections to certain websites. With SNI 
encryption this becomes ineffective. This draft should describe the privacy 
impact of enterprises adopting the proposed mitigation strategy of deploying 
monitoring software.  Similarly, the privacy impact of introducing "opt in" 
filtering of DNS and packet marking to determine QoS should be addressed. The 
privacy gains of encrypting SNI need to be weighed against the privacy losses 
of adopting these mitigations and at the moment this draft does not do that.


Section 3.6 "Proper security context"
This section currently describes one class of solutions where there is a single 
TLS handshake between the client and the multiplexed server or fronting 
service, but there is another class, where the TLS handshake is between the 
client and the protected service. The text in this section should be expanded 
to encompass both classes (or it could be written as two separate sections if 
clearer). The text should also draw out that the client and the protected 
service are placing a great deal of trust in the fronting service, which 
becomes a very powerful part of the network and hence a very attractive target 
for attackers or malicious operators.

As a suggestion, consider the following alternative text for section 3.6:


We can design solutions in which the multiplexed server or a fronting service 
act as a relay to reach the protected service. Some of those solutions involve 
just one TLS handshake between the client and the multiplexed server (or 
fronting service). Others involve just one TLS handshake between the client and 
the protected service.

In the first case, the master secret is verified by verifying a certificate 
provided by the multiplexed server (or fronting service), but not by the 
protected service. In the second case, the master secret is verified by 
verifying a certificate provided by the protected service.

In the first case, the client is exposed to a Man-In-The-Middle attack by the 
multiplexed server (or fronting service). The client does not verify the 
identity of the protected service, and thus data exchanged between the client 
and the protected service can be learned by the attacker. In the second case, 
the client does not verify the identity of the multiplexed server (or fronting 
service), thus it is possible for an attacker to perform a Man-In-The-Middle 
attack between the client and the multiplexed server (or fronting service). 
Thus it would be possible for the attacker to learn the identity of the 
protected service.

These designs require that the client has some reasonable trust in these 
fronting services. If the fronting service is acting maliciously, it may 
re-direct the client's TLS connection to another service other than the 
intended protected service. The service receiving the client's TLS connection 
may not have any way of verifying that the client intended to reach that 
particular service if it is not able to decrypt the client's SNI; thus the 
protected service also has to have reasonable trust in the fronting service. If 
the fronting service is not strongly authenticated, it can be spoofed by an 
adversary or be subject to MITM attack.

The multiplexed server or the fronting services could be pressured by 
adversaries. By design, they could be forced to deny access to the protected 
service, or to divulge which client accessed it. But if MITM is possible, the 
adversaries would also be able to pressure them into intercepting or spoofing 
the communications between client and protected service.

These approaches therefore concentrate trust in the multiplexed servers and 
fronting services, making them attractive targets for adversaries, or for 
operators of these services to install monitoring, redirection and censorship 
mechanisms.  It is desirable for the identity of these multiplexed servers and 
fronting services to be strongly authenticated and verifiable by both the 
client and the protected service.


-- Mark





This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC

[Mark O]

A couple of comments on draft-ietf-tls-tls13-vectors-06:
Ordering of messages:

  *   Whenever the steps '{server}  derive secret "tls13 c hs traffic":' and 
'{server}  derive secret "tls13 s hs traffic":' appear, this is corresponding 
to the steps in the second phase of the key schedule (section 7.1 of tls13-28)
  *   To complete these you need to have the encoded ServerHello message (as 
seen in 'Derive-Secret(., "c hs traffic", ClientHello...ServerHello)').
  *   The description of the ServerHello message doesn't come until several 
steps later. Someone using the test vectors to create unit tests would need to 
look ahead to the ServerHello payload (after '{server}  send handshake 
record:', starting with 'payload (90 octets):  02 00 00') before they can 
recreate the steps above.
Coalescence of records:
There are several examples where multiple messages are shown concatenated, both 
in their payload and ciphertext forms, which makes it much harder to test them. 
Concatenating them (or not) has no effect on the protocol, so it's not a 
requirement. It would be helpful to split out the messages so that it's clearer 
which bytes belong to which message. The first example of this is after 
"{server}  send a EncryptedExtensions handshake message", "{server}  send a 
Certificate handshake message", "{server}  send a CertificateVerify handshake 
message", and "{server}  send a Finished handshake message"; starting with 
"payload (657 octets):  08 00 00".

  *   Mark

This information is exempt under the Freedom of Information Act 2000 (FOIA) and 
may be exempt under other UK information legislation. Refer any FOIA queries to 
ncscinfo...@ncsc.gov.uk
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls