Subject: [TLS] Fwd: New Version Notification for draft-kazuho-protected-sni-00.txt

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jul 2017 05:42:24 +0200

Hi,

I am happy to see us having discussions on how to protected SNI. I am
also happy to see that draft-huitema-tls-sni-encryption [1] proposes
actual methods that we might want to use, and that the I-D discusses
about various attack vectors that we need to be aware of.

On the other hand, as stated on the mailing list an on the mic, I am
not super happy with the fact that the proposed methods have a
negative impact on connection establishment time.

So here goes my straw-man proposal, as an Internet Draft:
https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

In essence, the draft proposes of sending information (e.g.,
semi-static (EC)DH key) to bootstrap encryption in ClientHello as a
DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

Since DNS queries can run in parallel, there would be no negative
performance impact, as long as DNS responses can be obtained in a
single RTT.

The draft mainly discusses about sending a signed bootstrap
information together with the certificate chain, since doing so is not
only more secure but opens up other possibilities in the future (such
as 0-RTT full handshake). However, since transmitting a bootstrap
record with digital signature and identity is unlikely to fit in a
single packet (and therefore will have negative performance impact
until DNS over TLS or QUIC becomes popular), the draft also discusses
the possibility of sending the EC(DH) key unsigned in the "Things to
Consider" section.

I would appreciate it if you could give me comments / suggestions on
the proposed approach. Thank you in advance.

[1] https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2017-07-19 5:38 GMT+02:00
Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
To: Kazuho Oku <[email-masked]>

A new version of I-D, draft-kazuho-protected-sni-00.txt
has been successfully submitted by Kazuho Oku and posted to the
IETF repository.

Name:           draft-kazuho-protected-sni
Revision:       00
Title:          TLS Extensions for Protecting SNI
Document date:  2017-07-19
Group:          Individual Submission
Pages:          9
URL:
https://www.ietf.org/internet-drafts/draft-kazuho-protected-sni-00.txt
Status:         https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/
Htmlized:       https://tools.ietf.org/html/draft-kazuho-protected-sni-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-kazuho-protected-sni-00

Abstract:
   This memo introduces TLS extensions and a DNS Resource Record Type
   that can be used to protect attackers from obtaining the value of the
   Server Name Indication extension being transmitted over a Transport
   Layer Security (TLS) version 1.3 handshake.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
Kazuho Oku

---

From: Tom Ritter <[email-masked]>
Date: Tue, 18 Jul 2017 23:03:09 -0500

If I remember correctly, the idea of enabling SNI encryption (and
0RTT) via DNS had been brought up very early on in the discussion.
draft-nygren-service-bindings was the first (only? major?) concrete
proposal.

In general, I think the feedback was "DNS gets filtered to only
A/CNAME records so frequently that anything that relies on other DNS
records isn't going to work an appreciable portion of the time".

I'm disappointed by this also; but as we are also trying to deploy DNS
privacy - mechanisms that rely on an easily surveilled, censored, or
blocked mechanism to enable other sorts of privacy are concerning.

-tom

On 18 July 2017 at 22:42, Kazuho Oku <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jul 2017 06:49:58 +0200

Hi,

Thank you for the response.

I was not aware that the penetration rates of minor DNS records were
low. I will read the I-D and the mailing list archive.

OTOH, I think that the penetration rate being low might not be a
killer for the proposal, since in the short term, SNI encryption can
be an opportunistic feature, considering the fact that DNS packets
will be sent in cleartext anyways.

It might be possible to query for the A record and the bootstrap
record simultaneously and activate SNI protection only if responses to
both queries are obtained.

-- 
Kazuho Oku

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 19 Jul 2017 08:05:13 +0300

> https://datatracker.ietf.org/doc/draft-kazuho-protected-sni/.

At least that method does not obviously vulernable to replay. However,

> DNS record. Clients will use the obtained (EC)DH key to encrypt SNI.

There are multiple problems with use of DNS:

- Individual DNS records can be at most 64kB.
- The whole DNS reply can be at most 64kB.
- In practice, exceeding about 1200 bytes for response starts
  causing problems with DNSoDTLS (there is a fallback to DNSoTLS,
  but it is not very pleasant).
- The textual representation starts getting unpleasant way before
  that.
- DNS records are defined to have textual and wire formats. Using TLS
  notation would be pretty great for latter, but not good for the
  former.

> performance impact, as long as DNS responses can be obtained in a

Unfortunately, this is not quite true:

- Packets can get lost, and DNS retransmissions are fairly slow.
- There are lots of horked DNS servers that respond in all sorts of
  bad ways (including timing out, or sending utterly bogus error
  codes) to unknown RRTypes, especially if the RRType number is
  above 255 (but bad servers that do that to any RRType they do
  not know about still exist).

(And let's also ignore difficulties in adding new RRTypes, despite
RFC3597 being almost 14 years old, and covering almost everything that
has been added (one needs extra justfication for breaking RFC3597-
complatiblity[1]).)

[1] In practicular, following kinds of things break RFC3597:

- Compressing RRDATA with reference to rest of the DNS message (e.g.,
  DNS name compression).
- Requiring any kinds of transofrmations on the data in path between
  the master file and the end application.

> the possibility of sending the EC(DH) key unsigned in the "Things to

There is not much space in DNS records for anything bigger than one
ECDH key per record (but there is space for a few records of that
kind).

-Ilari

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 19 Jul 2017 10:37:20 +0200

Hi,

Thank you for your comments.

>   but it is not very pleasant).

Yes. It is very unlikely that a TLS bootstrap record that contains a
signature and a certificate chain will fit into a single packet, hence
there would be a performance penalty if DNS over DTLS that fallback to
TLS is used.

I have had DNS over QUIC in mind when writing the draft, and I might
say that the draft (especially the mode that bootstraps the _signed_
signature) is written under the premise that DNS over QUIC will become
popular in the future.

>   notation would be pretty great for latter, but not good for the

Generally speaking, for the following two reasons, I prefer having a
TLS structure that defines how a bootstrap information should be
encoded, and then have a DNS record type that conveys the information.

First reason is because the certificate chain and the signature that
signs the EC(DH) keys ideally should be validated the same way as we
do with the server certificates transmitted within a TLS handshake. It
would make sense to just convey certain extensions that affect the
behavior of validation (e.g., OCSP stapling extension) as-is, rather
than trying to come with corresponding textual representations.

Second reason is that we might want to transmit the bootstrap record
using something other than DNS.

>   not know about still exist).

If DNS over QUIC (or TLS) is used to transfer a signed bootstrap
record with a certificate chain, the amount of data that is sent (in
sum of DNS query and TLS handshake) will be roughly the same, assuming
that Cached Information Extension (RFC7924) is used. Therefore, I
believe that the performance will be roughly the same even when taking
packet loss into consideration.

If UDP-based DNS protocol is used to transfer a signed bootstrap
record with a certificate chain, the DNS query needs to fallback to
TCP, since the record does not fit into a single packet. That means
that it would never be possible to obtain the DNS response in 1 RTT in
such case.

If UDP-based DNS protocol is used to transfer a bootstrap record
without a sign or a certificate chain, then the question will be how
high the probability will be in the following two cases: lose more
than 1 packet within 2 packets vs. lose more than 1 packet within 4
packets. I agree that amortized performance will be worse for the
latter.

> ECDH key per record (but there is space for a few records of that

Agreed.

-- 
Kazuho Oku