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

[Ilari Liusvaara <[e-mail]>]

On Wed, Jul 19, 2017 at 05:42:24AM +0200, Kazuho Oku wrote:
> 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/.

At least that method does not obviously vulernable to replay. However,
it has multitude of other problems:

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

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.

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

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

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