Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Martin Thomson]

On 5 August 2017 at 01:30, Brian Sniffen  wrote:
> ## Don't stand out
>
> I think the requirement that the browser check the CT log and perform
> DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I
> don't expect most browsers to do that most times.  Am I missing
> something?

Checking the CT log or doing DNSSEC validation would definitely cause
a red flag, but if the DNSSEC chain extension to TLS is used
(consistently), then the information is already on hand.  I don't know
what can be done for CT (SCT likely isn't what we're looking for
here).

The conclusion to the ORIGIN frame discussion ended with two choices
that increase confidence that a certificate isn't mis-issued without
violating this principle.  That was OCSP stapling or SCT.  It's an
important principle, maybe this draft should be clearer about that.

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

Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Brian Sniffen]

Having promised a review before August 18, I have three issues I'd like
to talk about.  But first, thanks for keeping pushing on this.  I am not
sure it will ever see wide adoption, but we'll surely never find out if
we don't try.


## Don't stand out

I think the requirement that the browser check the CT log and perform
DNSSEC in 3.2 is likely to violate the don't-stand-out requirement, as I
don't expect most browsers to do that most times.  Am I missing
something?


## CDN integration

> If N multiple domains on a CDN are acceptable fronts, then we may
> want some way to indicate this without publishing and maintaining N
> separate tokens.

Those multiple domains will not share TLS keys (or will be under a TLS
wildcard), so delegation to a certificate is enough to cover this.  I
think you can just cut this paragraph, but maybe I don't know something
about some sort of CDN?


## Security considerations: DDoS

In section 6, I'm glad to see analysis vs the ddos requirements in 2.3.
I'm not sure I agree with the quick result:

1) The forwarding server can be used as a reflector.  Under some
   circumstances it should back off.

2) Under CPU load, the forwarding server will presumably start refusing
   early data (especially early data with TCP Fast Open!).  Is it
   necessary to say anything more here?  Or is the ordinary behavior of
   flaky early data sufficient?

   Particularly: what should clients do when early data is refused?  Try
   again with this in the main data section?  Give up?

-Brian

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

Re: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Kazuho Oku]

Thank you for writing the draft.

I agree for the need to hide hostnames from passive attackers, and I really
like the fact that the draft discusses of various attack vectors that a
proper SNI protection should take care of.

OTOH, it makes me sad that the proposed methods require an additional
roundtrip (when compared to no encrypted SNI).

Can't we consider adopting a method that improves both performance and
privacy, instead of choosing one between the two?

Specifically, I wonder if we could consider embedding part of the TLS
handshake within a secure DNS query / response. That will make the
connection setup even faster than today at the same time providing us more
privacy.

Note that regardless of the approach, it is mandatory to migrate DNS onto a
secure channel (i.e. over TLS or QUIC) in order to protect the hostname
that the client is going to access. Protecting just the SNI is insufficient.

Approach 1. embed TLS handshake in the DNS query and response

A client queries a DNS over a secure channel. ClientHello is embedded to
the DNS query. The resolver that receives the query will always contact the
authoritative server by using a secure channel, transmitting both the DNS
query and the ClientHello. Upon receiving the query, the authoritative
server will send a DNS response that embeds the server's first flight of
the TLS handshake (i.e. from ServerHello to ServerFinished). The resolver
relays the DNS response (with the handshake messages) to the client.

When the client receives the DNS response and the TLS handshake messages,
it connects to the server (that is designated by the DNS response) and
immediately sends the client's second flight of the TLS handshake (i.e.
ClientFinished) with an identifier that correlates that message to the
first flight of the messages transmitted through DNS, followed by
application data.

The merit of the approach is that connection setup will be even more faster
than now, since the time being spent changes from 1 RTT-to-DNS + 1
RTT-to-origin to 1 RTT-to-origin-through-DNS (note that reducing the
roundtrip to DNS has become important than before due to the fact that
resolvers are less common to be located near the client. This is especially
the case for mobile networks). Though there could be replay issues until
the client receives the server's first flight through the direct connection.

In short, the connection setup latency (including DNS) will be reduced from
2 RTT to 1 RTT, whereas in the approaches that are discussed in the draft
it will change from 2 RTT to 3 RTT.

Approach 2. embed TLS handshake originating from the server in DNS response

This is a variation of the former approach.

In this approach, a DNS query is sent over a secure channel but does not
convey any TLS handshake massage. OTOH it is the server that initiates the
handshake, upon receiving a DNS query. The DNS response (sent over a secure
channel) will include the necessary parameters to establish an end-to-end
secure channel (e.g. nonce, cryptographic parameters, server certificate,
and a signature signing the values). When the client receives the DNS
response that contains the handshake messages, it will use that to
establish a secure connection to the server (by sending it's nonce and the
negotiated parameters that are signed).

The time required for establishing a connection will be the same as the
first approach.

However, one interesting difference from the former approach is that it
will be possible for a DNS resolver to cache the DNS response including the
server's first flight of the handshake messages (at the cost of losing
single-op DH). Hence the change required to existing DNS infrastructure
could be somewhat smaller.

The risk would be that if the resolver reuses the DNS response, a passive
observer could determine whether if multiple new connections went to the
same origin (by looking at the identifier that designates the handshake
that the client is responding to). If that is an issue, a client may want
to inject randomness into the query to suppress the resolver from reusing
the response.

2017-06-22 13:25 GMT+09:00 Christian Huitema :

> We has many discussions of SNI encryption on this list recently, and that
> was enough motivation to write a draft about it. I am pretty sure that this
> will be met with wide approval and no discussion at all :-).
>
> -- Christian Huitema
>
>  Forwarded Message 
> Subject: New Version Notification for draft-huitema-tls-sni-
> encryption-00.txt
> Date: Wed, 21 Jun 2017 21:17:26 -0700
> From: internet-dra...@ietf.org
> To: Christian Huitema  , Eric
> Rescorla  
>
> A new version of I-D, draft-huitema-tls-sni-encryption-00.txt
> has been successfully submitted by Christian Huitema and posted to the
> IETF repository.
>
> Name: draft-huitema-tls-sni-encryption
> Revision: 00
> Title:SNI Encryption in TLS 

[TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt

[Christian Huitema]

We has many discussions of SNI encryption on this list recently, and
that was enough motivation to write a draft about it. I am pretty sure
that this will be met with wide approval and no discussion at all :-).

-- Christian Huitema

 Forwarded Message 

Subject:New Version Notification for
draft-huitema-tls-sni-encryption-00.txt
Date:   Wed, 21 Jun 2017 21:17:26 -0700
From:   internet-dra...@ietf.org
To: Christian Huitema , Eric Rescorla 



A new version of I-D, draft-huitema-tls-sni-encryption-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:   draft-huitema-tls-sni-encryption
Revision:   00
Title:  SNI Encryption in TLS Through Tunneling
Document date:  2017-06-20
Group:  Individual Submission
Pages:  19
URL:
https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
Htmlized:   https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00


Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing known attacks against SNI encryption, and then presents two
   potential solutions that might mitigate these attacks.  The first
   solution is based on TLS in TLS "quasi tunneling", and the second
   solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.


  


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

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