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

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 <kazuhooku@gmail.com> 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/.
>
> 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:  <internet-drafts@ietf.org>
> Date: 2017-07-19 5:38 GMT+02:00
> Subject: New Version Notification for draft-kazuho-protected-sni-00.txt
> To: Kazuho Oku <kazuhooku@gmail.com>
>
>
>
> 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
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls