Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3 after all?

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Dec 2015 11:12:47 +0200

> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum <[email-masked]> wrote:
> 
> On 12/1/15, Viktor Dukhovni <[email-masked]> wrote:
>> On Mon, Nov 30, 2015 at 10:34:27AM +0000, Peter Gutmann wrote:
>> 
>>> Bryan A Ford <[email-masked]> writes:
>>> 
>>>> It would work just as well and in exactly the same way if the AEAD is
>>>> replaced with the traditional Encrypt-then-MAC construction, for
>>>> example.
>>> 
>>> No it wouldn't, unless the encrypt part is a stream cipher.  You're still
>>> locked into using an AEAD stream cipher or the equivalent of an AEAD
>>> stream
>>> cipher built with encrypt+MAC.  It won't work with, for example, the OCB
>>> AEAD
>>> mode, or CBC + MAC.
>> 
>> I think we should focus on what would get TLS 1.3 to be adopted:
>> 
>>    * Reasonably implementable in libraries that support older
>>      versions alongside TLS 1.3.
>> 
> 
> That doesn't change with Bryan's suggestion, I think.
> 
>>    * Interoperable in the field with various capital-intensive
>>      middle boxen.
> 
> Which would those be? And what is the definition of capital-intensive
> for those watching on the sidelines?

Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on protocols to make sure that the stuff going over TCP port 443 is really HTTPS rather than an attempt at tunneling.  There are some attacks such the the code that protects against them needs to follow TLS record sizes. For the most part these are not-so-interesting attacks, causing certain versions of certain browsers to hang, and they are expensive for the firewall to protect against, so for the most part these protections are turned off. But it’s not everywhere.

If enough middleboxes block TLS 1.3, the browsers will implement a downgrade dance. If they do that, attackers will be able to exploit the downgrade dance. I don’t think the net effect is better security. We’d be far better off writing a separate document on how to use the padding feature that is already in 1.3 to mitigate traffic analysis without actually flooding your Internet connection. Splitting records and padding a few can be more effective than masking the length bits.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Tue, 01 Dec 2015 12:02:07 +0100

On Tuesday 01 December 2015 00:14:14 Jacob Appelbaum wrote:
> On 11/30/15, Hubert Kario <[email-masked]> wrote:
> > On Monday 30 November 2015 10:58:48 Bryan A Ford wrote:
> >> On 11/30/15 2:40 AM, Peter Gutmann wrote:
> >> > Nikos Mavrogiannopoulos <[email-masked]> writes:
> >> >> I believe your proposal is a nice example of putting the cart
> >> >> before the horse. Before proposing something it should be clear
> >> >> what do you want to protect from, what is the threat?
> >> > 
> >> > Exactly.  If you want to thwart traffic analysis, you need to do
> >> > something like what's done by designs like Aqua ("Towards
> >> > Efficient
> >> > Traffic-analysis Resistant Anonymity Networks"), or ideas from
> >> > any
> >> > of the other anti-traffic- analysis work that's emerged in the
> >> > past
> >> > decade or two.
> >> 
> >> I'm well aware of Aqua and "the other anti-traffic-analysis work
> >> that's emerged in the past decade or two": in fact I led one of the
> >> 
> >> major recent systematic projects in that space.  See for example:
> >> 	http://dedis.cs.yale.edu/dissent/
> >> 	http://cacm.acm.org/magazines/2015/10/192387-seeking-anonymity-in-> >> 	an->>> 
> >> internet-panopticon/fulltext
> >> 
> >> > You get traffic
> >> > analysis resistance by, for example, breaking data into
> >> > fixed-length
> >> > packets, using cover traffic, and messing with packet timings,
> >> > not
> >> > by
> >> > encrypting TLS headers.
> >> 
> >> Packet padding and header encryption are both important,
> >> complementary security measures: you get security benefits from
> >> each that you don't get from the other.  Yes, you need padding to
> >> obtain systematic protection from traffic analysis - when for
> >> whatever reason not all implementations are always padding to the
> >> exact same standardized record length, header encryption makes
> >> padded streams less trivially distinguishable from unpadded
> >> streams, and makes streams with different record sizes less
> >> trivially distinguishable from each other.
> > 
> > the header contains only one piece of information, and it is public
> > already - the amount of data transmitted*
> 
> I'm pretty sure TLS has a lot more data...

in TLS v1.3 no, it doesn't. All encrypted packets must have the 
plaintext record type set to Application Data[1], same for version - 
it's frozen now at 3.1 (TLS1.0)[2], both are used just as a magic value.

> > this goes well past the TLS WG charter, if only because it requires
> > very close cooperation with the application layer
> > 
> > so while the padding mechanism should be there, we really can't
> > describe how it needs to be used, as it can't be made universal nor
> > is it necessary for all use cases
> 
> I think it should be described how it needs to be used...

Yes, I misspoke. What I meant is that we can't mandate its use as it is 
an application layer issue. We definitely should describe how it needs 
to be used on TLS level.

> >  * - sure, the record layer boundaries can tell something about the
> >  data> 
> > being transmitted, but so can the presence of data transmission
> > taking place in the first place (think of a station sending reports
> > only when it detects something while keeping connection open the
> > whole time)
> Yes, they tell something and that something is better removed.

then we need Best Current Practice for applications describing to them 
how TLS needs to be used, e.g. make sure that they are doing writes as 
big as possible, checking if timing of responses doesn't leak much 
information, etc. Forcing TLS implementation to combine writes will 
easily cause serious problems with interactivity of sessions...

> >> One thing that would greatly help Tor and all similar,
> >> padded protocols is if they could "blend in" even just a little bit
> >> better with the vast bulk of ordinary TLS-encrypted Web traffic,
> >> and
> >> that's one of the big opportunities we're talking about here.
> > 
> > the initial message in handshake in TLS MUST stay the same thus it
> > is
> > impossible to make it look like Tor. Not to thwart the Pervasive
> > Monitoring threat of TLA agencies.
> 
> That Tor claim is strange and seemingly false in any case. Also, I've
> said it before quoting the RFC but I'll say it again: Pervasive
> Monitoring is an attack.

Not claiming it isn't. But some things (like compression) are best done 
at application layer, not TLS layer.
 
> >> If you think it is practical for the TLS 1.3 standard to specify a
> >> single, fixed record size that all implementations of TLS 1.3 must
> >> use (i.e., explicitly freeze not only the version field but the
> >> length field), then that would be great for traffic analysis
> >> protection and on that basis I would support that proposal.  But
> >> that frankly seems to me likely a bit too much to ask given the
> >> diversity of TLS implementations and use-cases.  Tell me if you
> >> believe otherwise.> 
> > That will just round up to a multiple of 256 bytes the data sizes
> > transmitted. Hardly an improvement over the current 16 byte blocks.
> 
> Closer to 512 bytes is better.

Either hardly helps if you're not transferring packets with null data to 
really hide the amount of data transferred.

 1 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2
   opaque_type
      The outer opaque_type field of a TLSCiphertext record is always
      set to the value 23 (application_data) for outward compatibility
      with middleboxes used to parsing previous versions of TLS.  The
      actual content type of the record is found in fragment.type after
      decryption.
 2 - https://tools.ietf.org/html/draft-ietf-tls-tls13-10#section-5.2.2
   record_version
      The record_version field is identical to
      TLSPlaintext.record_version and is always { 3, 1 }.  Note that the
      handshake protocol including the ClientHello and ServerHello
      messages authenticates the protocol version, so this value is
      redundant.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 01 Dec 2015 14:15:00 +0100

Hi,

> easily cause serious problems with interactivity of sessions...

FYI: similar IETF documents like that exists for TLS (up to 1.2)
already. Might make sense to update them or have similar ones when time
comes. Though spreading everything out over a lot of documents makes it
harder for implementers to find all the information they might be
looking for, IMO. Actually, as far as I understand the whole objective
of UTA-WG is putting out documents like that (Utilizing TLS in
Applications).

https://tools.ietf.org/html/rfc7457
https://tools.ietf.org/html/rfc7525

Aaron

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Dec 2015 16:22:23 +0200

> really hide the amount of data transferred.

I think this is not as black and white as you suggest. 

It is possible to totally hide the actual data stream by sending a constant-rate stream of constant-size data records regardless of the availability of actual data. This is a perfect counter-measure to traffic analysis but it has a huge cost in bandwidth. Endpoints who do that might well be considered to be DoS-ing the network. 

There are less drastic ways. You could add small variations to the timing and sizes of records, adding a little padding, splitting and combining the application writes, perhaps with the addition of the occasional burst of fake traffic. This can have a relatively small overhead and obscure the real sizes and number of requests. An attacker will still have an approximation of the amount of real traffic is actually passed, but would not be able to guess which Wikipedia article you are viewing or what part of the world you are looking at with your favorite maps website. This is not as perfect as the full traffic flow confidentiality above, but it would be more palatable to network administrators and to people who pay for Internet access by the megabyte.

I don’t think this is the same as encryption where you either have perfect security or you have nothing at all. There can be incremental gains that are worth having at significantly lower cost than the perfect TFC.

Yoav

---

From: John Mattsson <[email-masked]>
Date: Tue, 1 Dec 2015 14:53:16 +0000

On 01/12/15 15:22, "TLS on behalf of Yoav Nir" <[email-masked] on
behalf of [email-masked]> wrote:

>It is possible to totally hide the actual data stream by sending a
>constant-rate stream of constant-size data records regardless of the
>availability of actual data. This is a perfect counter-measure to traffic
>analysis but it has a huge cost in bandwidth. Endpoints who do that might
>well be considered to be DoS-ing the network.
>
>There are less drastic ways. You could add small variations to the timing
>and sizes of records, adding a little padding, splitting and combining
>the application writes, perhaps with the addition of the occasional burst
>of fake traffic. This can have a relatively small overhead and obscure
>the real sizes and number of requests. An attacker will still have an
>approximation of the amount of real traffic is actually passed, but would
>not be able to guess which Wikipedia article you are viewing or what part
>of the world you are looking at with your favorite maps website. This is
>not as perfect as the full traffic flow confidentiality above, but it
>would be more palatable to network administrators and to people who pay
>for Internet access by the megabyte.
>
>I don’t think this is the same as encryption where you either have
>perfect security or you have nothing at all. There can be incremental
>gains that are worth having at significantly lower cost than the perfect
>TFC.
>
>Yoav

While I support anything increasing privacy, I think a traffic flow
confidentiality mechanism should be optional to use (like in ESP RFC4303),
and not mandatory to use. The are still many use cases where where
bandwidth is not abundant, e.g. many wireless networks such as 2G, 3G,
802.15.4. Padding and dummy packets may significantly increase the number
of bytes. We should not end up in scenario where D(TLS) 1.3 is not used in
some scenarios because of an increase in overhead.

John

---

From: Bryan A Ford <[email-masked]>
Date: Tue, 1 Dec 2015 15:55:21 +0100

> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on protocols to make sure that the stuff going over TCP port 443 is really HTTPS rather than an attempt at tunneling. There are…

Certainly there are middleboxes that try to use traffic analysis to
detect attempts at tunneling - but the fact that the traffic is HTTPS
doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation
does exactly that (and is sometimes used for exactly that purpose).

Regardless, does the IETF really want to be in the business of making
sure that protocols like TLS are designed to avoid making life
inconvenient for developers of Great Firewalls of whatever type?

> If enough middleboxes block TLS 1.3, the browsers will implement a downgrade dance. If they do that, attackers will be able to exploit the downgrade dance. I don’t think the net effect is better se…

Browsers have to implement a downgrade dance anyway to be able to talk
with web servers that don't support TLS 1.3.  TLS 1.3 already changes
plenty of things that middleboxes "might" not like; absent concrete
evidence of major incompatibilities specifically caused by the proposed
change, I don't see why we should avoid changing one more bit of the
protocol that middlebrowsers "might" not like.

B

---

From: Bryan A Ford <[email-masked]>
Date: Tue, 1 Dec 2015 16:27:31 +0100

On 12/1/15 4:02 AM, Fabrice Gautier wrote:
> 1) What would be the implications of this for DTLS? (Knowing that one difference between TLS and DTLS is the record header)

Good question.  Fortunately my proposal should be fairly easy to adapt
to DTLS, with one small trick.

The main issue is that DTLS packets need to contain explicitly
transmitted sequence numbers rather than implicit sequence numbers,
because packets can be received out of the order and the receiver needs
to know which sequence number (and hence which nonce) to use to try to
decrypt and integrity-check.  But if we encrypt the full DTLS header
including sequence number, how does the receiver decrypt it without
knowing the correct nonce to use to decrypt it?  An apparent
chicken-and-egg problem.

Fortunately the solution is fairly simple: the receiver simply
pre-computes and keeps in a small hash table the encrypted sequence
numbers of all packets with sequence numbers between H-W and H+W, where
H is the highest sequence number correctly received so far (the horizon)
and W is the anti-replay window size as specified in 4.1.2.5 of RFC
4347, which typically should be 32 or 64 according to the RFC.  The
receiver can precompute all these encryptions because in my proposal TLS
headers are encrypted with a stream cipher (or the AEAD operating as a
stream cipher), so it's just a matter of producing the correct
cipherstream bytes and XORing them with the uint48 sequence number.

Whenever the receiver gets a datagram, it looks up the encrypted
sequence number in the hash table, drops it on the floor if it's not
present, and if it's present the receiver gets the decrypted sequence
number from the hash table and uses that in the AEAD decryption and
integrity-check.  In the low-probability event of a hash-table collision
(i.e., two uint48 sequence numbers encrypting to the same 48-bit
ciphertext in a single 129-datagram window), the receiver can
trial-decrypt with both (or all) sequence numbers in that colliding hash
table entry.  Or the receiver can keep it even simpler and just drop all
but one colliding entry, introducing a pretty low probability of
introducing occasional "false packet drops."

The hash table is pretty trivial to maintain efficiently as well: e.g.,
whenever the horizon H moves forward by delta D, remove the first D
entries from the current window and precompute another D encrypted
sequence numbers (where D will most often be 1).  In the simple design
that doesn't bother dealing with hash table collisions (e.g., that
allows each hash table entry to contain only one value), perhaps don't
even bother clearing/removing old entries; just gradually overwrite them
with new ones as H moves forward.

> 2) In some implementations the record framing/parsing and encryption/decryption are down at different layers. Would this proposal make this type of implementation impossible? 

Not that I'm aware of, but I might need more information about the
specific layering approaches you're thinking of and how "strongly
enforced" that layering might be.  But in the version of my proposal
that operates the "normal" AEAD as a stream cipher for header
encryption/decryption purposes, it doesn't seem like any change would be
needed to the standard AEAD encryption/decryption interface.  It should
even be fine if the AEAD was implemented as a separate hardware module
that takes the standard AEAD interface inputs and produces the standard
AEAD outputs; as long as it supports the standard AEAD API it should be
perfectly usable in the design I proposed.

The one potential issue I can think of if a particular, restricted API
forces the caller to commit at key-setup time to either "AEAD encryption
mode" or "AEAD decryption mode", and makes it difficult or impossible to
switch back and forth.  In that case in my proposal as it stands the
receiver TLS implementation might need to set up and maintain two
hardware contexts, one for AEAD decryption (for the payloads), the other
for AEAD encryption (for stream cipher header decryption), both using
the symmetric key.  This still doesn't seem all that problematic to me,
though, and I don't even know of any particular APIs offhand that
present this particular issue.

Cheers
Bryan

---

From: Bryan A Ford <[email-masked]>
Date: Tue, 1 Dec 2015 17:22:13 +0100

Some of the parallel discussion on the SSH list - especially comments by
Simon Tatham and Niels Möller - made me think of an alternative design
that would not only hide TLS headers but also ensure that they are
integrity-checked by the receiver *before* the receiver attempts to
interpret the record header in any way.  This alternative approach
already feels to me like an improvement over my last one, and perhaps
even those who are skeptical of the need to encrypt TLS headers might
appreciate the desirability of closing vulnerabilities to
length-fiddling attacks: e.g., where an attacker sets the high bit of
the length field in the last TLS record so that the receiver will likely
hang on a long read before detecting the change.

Proposal:

The basic idea is in some respects even simpler than the last one:

1. We move the TLS header from the "additional data" field to the start
of the "plaintext" field.  That is, the sender encrypts the header along
with the payload, and the receiver decrypts and integrity-checks the
header along with the payload, using the standard AEAD interface.  The
"additional data" field now contains *only* the sequence number, which
both sender and receiver track and compute implicitly.

2. The 2-byte length field in each record's header no longer indicates
the length of the *current* record but instead indicates the length of
the *next* record.  The length of the first record might be defined in a
new field we add to the handshake/key-exchange protocol, or it might
simply be set to some well-known standard first record size.

That's basically it.  The key advantage is that this way the receiver
always "knows" the correct size of each record before having to read or
interpret any part of it in any way.  In fact, because the record is
fully encrypted, the receiver implementation is basically forced to use
the AEAD to decrypt and integrity-check the record before doing anything
at all with it, which closes down not only the well-known
length-fiddling attack that has dogged SSH, but a whole class of
possible potential implementation bugs regarding the (delicate) handling
of cleartext TLS headers before they've been integrity-checked.
Basically, this ensures that if the receiver have any bugs in the
handling of the TLS header, they can be exploited only by its
communication partner, and not by an attacker in the middle of the path.
 To me this seems like a useful robustness benefit completely
independent of the (also desirable) benefits with respect to traffic
analysis.

Choosing next-record lengths:

Of course this approach presents the minor challenge that the sender
must always "commit" to the length of the next record before sending the
current one.  But this challenge is pretty easy to deal with.  The
easiest way to handle it, of course, is if the sender simply pads all
packets to the same record length - a solution I would generally be
quite happy with due to its complementary traffic analysis resistance
benefits, and I would even favor explicitly encouraging that solution in
the TLS RFC.  I would love it if the next TLS RFC ended up containing a
clause of the form:

	The TLS sender SHOULD always transmit TLS records of
	length exactly X, unless this is deemed impractical
	due to overriding performance or bandwidth-efficiency
	considerations.

...where "X" is some reasonable value we discuss and decide on.

But my (new) proposal does not require all TLS implementations to
maintain a fixed record size.  If the sender implementation wants to use
variable-size records, it can still process batches of records written
together normally up until the last record in the batch.  But when
processing the last record in a write - or in general the last record
before "going idle" where it does not yet have a next record to send -
the sender simply "picks something."  That something might for example
be a minimum record size, meaning the next record will be big enough to
hold a "next record length" indicating a useful length, but will
otherwise be basically a no-op record, so we'll pay the cost of an extra
small record and AEAD encryption/decryption each time transmission
resumes after being idle.

Alternatively the sender of variable-length records might pick a
"typical record size" as the next-record-size to transmit in the last
record in a burst; that way once transmission resumes the next record
can probably carry useful data, but might need padding if its committed
size is larger than the amount of data to be transmitted.  The
(important) existence of the padding mechanism already added in TLS 1.3
makes this alternative possible.

DTLS:

Now there's still the important question of whether this (new) proposal
could be made to work in the context of DTLS.  For the DTLS case, my
current thinking is that some elements of my earlier proposal is
probably more suitable: namely using a stream cipher (or AEAD used as a
stream cipher) to encrypt and recognize the explicitly-transmitted
sequence numbers that DTLS needs.  This could operate basically the same
as I described in my earlier E-mail on this topic.  Note that the length
field is no longer a problem in DTLS as it is in TLS, because the
receiver already gets the length of the datagram from UDP.

Comments/discussion?  Is the above more (or less) palatable than my
previous proposal?

Cheers
Bryan

---

From: Dmitry Belyavsky <[email-masked]>
Date: Tue, 1 Dec 2015 23:49:13 +0300

Dear Bryan,

On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <[email-masked]> wrote:

> receiver already gets the length of the datagram from UDP.
Do I understand correctly that your propose makes difficult to derive the
key from the original value depending on the sequence number?

-- 
SY, Dmitry Belyavsky

---

From: Bryan A Ford <[email-masked]>
Date: Tue, 1 Dec 2015 22:45:59 +0100

Hi Dmitry,

On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> Dear Bryan, 
> 
> On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     DTLS:
> 
> Do I understand correctly that your propose makes difficult to derive
> the key from the original value depending on the sequence number?

I'm not sure I understand your question; can you clarify?  What is the
"original value" you are worried about the key being derivable from?
Certainly if the cipher (stream cipher or AEAD) is working correctly, it
should make it cryptographically infeasible for an attacker to derive
the shared secret key from anything the protocol transmits.

Bryan

---

From: Fabrice Gautier <[email-masked]>
Date: Tue, 1 Dec 2015 15:54:51 -0800

> with new ones as H moves forward.

Hum.... I wouldn't qualify this as a "fairly simple" solution.

> enforced" that layering might be.

For example:
  A TLS library might be logically separated into two main parts:
1) A record parsing block, that just take a stream of bytes as in
input (eg: from a socket) and output a series a record.
2) A decrypt function, that take as input full encrypted record and
output a decrypted one.

There may be various reason to do this: flexibility, clean layering,
maintainability, testability, etc...

Another reason, maybe performance. For example, a network stack might
not want to send partial records to the application to decrypt. Having
a simple way for a network stack to implement TLS framing maybe
beneficial. Currently it would be fairly simple to implement TLS
record parsing in a TCP stack. But with your proposal it seems it
would mean the parsing layer would need to get keys and do crypto.

> But in the version of my proposal

This is all good, except that your proposal requires that the record
parsing layers has access to some AEAD API. So far it didn't need an
AEAD API at all.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 01:24:11 +0000

Jacob Appelbaum <[email-masked]> writes:

>I think the only thing that comes close is when I've named a classified US
>government surveillance program (XKeyscore) that would probably have trouble
>with it.

Why would XKeyscore have trouble with it?  Standard off-the-shelf routers, not
even specialised USG surveillance gear, does fairly sophisticated flow
tracing, packet reassembly, connection analysis, and so on.  It's built into
the router.  Encrypting the headers is, at best, a minor speedbump to
attackers (while being a major headache for implementers, particularly SSH's
way of doing it), because they can use the native capabilities of the routing
hardware to sidestep the need to decrypt headers.

If people really want to address this then they need to do the following:

1. Define a threat model.  What are we supposed to be defending against?

   (Note: The Inside-Out Threat Model, "this is the defence, anything that it
   prevents is what we're defending against", is not a threat model).

2. List the various measures that can be used to defend against the threat:
   Fixed-size packets, padding, quantised packet timing, etc.

3. Decide on which ones are necessary to defend against an actual threat, and
   which ones aren't, taking into account cost/benefit tradeoffs (is the
   effort/overhead involved worth the gain?).
   
4. Provide guidance for TLS and SSH developers on how they can implement
   these.

Once that's done (and in particular #1 and #2), we have a framework within
which we can decide whether encrypting lengths is worth the annoyance it
creates for implementers.

Without this, the debate over encrypted lengths is, to quote Linus, nothing
more than "people wanking around with their opinions" (and yeah, that includes
me).

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 1 Dec 2015 21:02:34 -0800

On 1 December 2015 at 08:22, Bryan A Ford <[email-masked]> wrote:
> The 2-byte length field in each record's header no longer indicates
> the *next* record.

Ensuring that you know the length of the *next* record is difficult
and could dramatically degrade latency, or adding extra bogus padding
or extra bogus records.  For instance, I can always send in bursts of
two packets, a one octet packet that promises the remainder of the
burst and one that promises a single octet packet.  At that point, I
get to do what I've always done and you have gained little other than
an increase in packet size of around 19 octets (best case).

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 2 Dec 2015 05:31:36 +0000

> an increase in packet size of around 19 octets (best case).

We're missing an opportunity to implement ATM again.  The magic
cell size is 53 bytes, 5 bytes of header and 48 bytes of payload.
With the cell length always 53 bytes, there's no longer any need
to send or encrypt that length. :-)

-- 
	Viktor.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2015 08:52:59 +0200

> On 1 Dec 2015, at 4:55 PM, Bryan A Ford <[email-masked]> wrote:
> 

Convenience has nothing to do with it. The next version of every firewall out there is going to support TLS 1.3. If TLS 1.3 means that the middlebox cannot parse the record lengths, then the next version of the middlebox will give the administrator the option of blocking TLS 1.3 or disabling the processing that requires following record lengths.  The issue is with all older version middleboxes that are out there. They don’t get updated nearly as often as we vendors would like. 

And the IETF is in the business of developing protocols that work and can be deployed. For counter-examples look at SCTP. It is not deployed because middleboxes (mostly NAT devices in this case) didn’t know what to do with it. It’s fairly simple to NAT SCTP, but the old middleboxes didn’t know how. Newer middleboxes still mostly don’t know how to NAT SCTP. Why? Because nobody’s using SCTP, so why bother? There are a dozen other features that customers actually want that need to be developed.

> protocol that middlebrowsers "might" not like.

That is not what a downgrade dance is. The normal way of version negotiation goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) OK, I choose 1.2.

By the end of the handshake both of the above messages enter the calculation of the Finished message so it’s fine.

A downgrade dance goes something like this:
Client: I support TLS 1.1, 1.2, and 1.3.
Server: (WTF is 1.3?) RST
Client: (old server that didn’t implement version negotiation right. Sigh) I support TLS 1.1, 1.2.
Server: OK, I choose 1.2.

In this case only the last two messages get into the Finished message. As a result, an attacker (whether on-path or not) can easily induce the downgrade dance by sending a RST, but it cannot induce version negotiation down to 1.2. Browsers are just now getting rid of the downgrade dance they had for 1.2. It would be a shame to have to re-introduce it.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2015 09:05:00 +0200

> On 2 Dec 2015, at 3:24 AM, Peter Gutmann <[email-masked]> wrote:
> 
> 

Fine. I’ll take a stab at it. But different people are concerned with different threats. So I’ll divide this into three layers of concern, because I think they build one on top of the other:

Concern Layer #1: I would like a passive observer to not be able to know the exact size of requests and responses in my stream as that could identify the resource name and content. Obvious example is from HTTPS. At this layer I’m fine about “them” (for whatever “them” I’m concerned about) knowing that I am browsing Wikipedia, but I don’t want them to know which article.

Concern Layer #2: I would like a passive observer to not be able to know how many requests I am making to the server at a given time. At this level I’m concerned that just the number of requests may leak something about what I am looking at. So if I’m looking at one of only 12 Wikipedia pages that have exactly 27 images it severely narrows down the list of what I’m looking for. 

Concern Layer #3: I would like a passive observer to not be able to know whether I am sending requests and getting responses at all. Obviously they can know that I have an HTTPS connection with en.wikipedia.org, but they should have no idea whether this connection is idle or downloading tons of content. 

I could add a fourth layer where I don’t want the observer to know whether or not I am looking at Wikipedia at all, but that is not something that I believe the TLS working group can do. This is more in-line with what Jacob is doing.

Yoav

---

From: Dmitry Belyavsky <[email-masked]>
Date: Wed, 2 Dec 2015 11:42:59 +0300

Dear Bryan,

> the shared secret key from anything the protocol transmits.

I mean something like http://tools.ietf.org/html/rfc4357#section-7
We have the keys calculated during the handshake and want to modify it for
each record.

-- 
SY, Dmitry Belyavsky

---

From: Bryan Ford <[email-masked]>
Date: Wed, 2 Dec 2015 10:07:33 +0100

> an increase in packet size of around 19 octets (best case).

That type of inefficiency is extremely easy to avoid; please read the rest of my proposal where I discussed exactly that at length.  Yes, a particularly stupid implementation could send everything in bursts of two packets, but it’s ridiculously easy for a slightly smarter implementation to avoid doing that.  And what you’ve gained is complete encryption and integrity-checking of the whole TLS record before any part is interpreted, which seems like a nontrivial security improvement.

B

---

From: Bryan Ford <[email-masked]>
Date: Wed, 2 Dec 2015 10:11:19 +0100

On 02 Dec 2015, at 09:42, Dmitry Belyavsky <[email-masked]> wrote:
> On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford <[email-masked] <mailto:[email-masked]>> wrote:
> I mean something like http://tools.ietf.org/html/rfc4357#section-7 <http://tools.ietf.org/html/rfc4357#section-7>
> We have the keys calculated during the handshake and want to modify it for each record. 

Hmmm - the RFC you point to is about the GOST cipher, and section 7 seems to be about “secret key diversification”, but I know nothing about GOST other than that it’s a cipher and it’s not obvious to me what exactly “secret key diversification” means here or what exactly it has to do with TLS (which works with many different ciphers).  I guess I still need a more detailed clarification of your question if I’m going to be able to try to answer it.

B

---

From: Bryan Ford <[email-masked]>
Date: Wed, 2 Dec 2015 10:51:55 +0100

On 02 Dec 2015, at 00:54, Fabrice Gautier <[email-masked]> wrote:
> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford <[email-masked] <mailto:[email-masked]>> wrote:
>> to DTLS, with one small trick. […]
> 

A reasonable but subjective position, which I think we should further discuss later if/when this (or some) WG actually revisits DTLS. :)

> would mean the parsing layer would need to get keys and do crypto.

In my first proposal, with headers encrypted with a stream cipher (or AEAD used as one), I think this kind of layering should still be quite feasible, with the one caveat that the TLS record parsing layer does indeed need to make one new “call” into the crypto-related code (to get the header) in addition to the one it already does (to pass the body and header to the crypto code for body-decryption and integrity-check).  And only on the receive path; the send path seems pretty much unaffected.  This doesn’t seem like a big layering problem to me, but again subjective opinions may vary.

In my second proposal, with headers fully encrypted and integrity-checked along with the body, I think the opportunity for the clean layering you propose comes back and perhaps gets even better: it’s just that the record writing/parsing now happens *inside* rather than outside the encryption boundary.  In other words, their order is reversed: the sender invokes the record-writing code first, then the AEAD encryption code to encrypt everything (header and data) at once; the receiver flow invokes the AEAD decryption code first to decrypt everything, then invokes the separately-modularized record parsing code on the already fully decrypted and integrity-checked record content.  This seems even cleaner to me than the current approach, where the record parsing code has to do some (very careful!) parsing of the record before it’s been authenticated, then invoke decryption, then do some more internal parsing on the decrypted AEAD body (e.g., the encrypted content-type within).

B

---

From: Bryan Ford <[email-masked]>
Date: Wed, 2 Dec 2015 11:03:41 +0100

>   prevents is what we're defending against", is not a threat model).

We have repeatedly stated several relevant threat models here; you just don’t seem to be accepting them as threat models for some reason.  One is the passive eavesdropping attacker, who can monitor flows but cannot easily inject traffic; mass monitoring of tapped fibre optic cables are one specific real-world example of that.  Another is the “partly-active” attacker who can inject packets but cannot readily prevent the legitimate packets from arriving; two very real-world examples of this are XKEYSCORE/QUANTUMINSERT and the WiFi internet cafe snooper.  In each of these real-world threat models the “dribble attack” to sniff out record boundaries via full MITM is not an option for the attacker, and hence there is potential benefit to encrypted record headers even without any other anti-traffic-analysis measures.

>   Fixed-size packets, padding, quantised packet timing, etc.

We have been doing this as well, repeatedly.  And as I’ve stated repeatedly and you have not refuted, having encrypted packet headers allows us to deploy some of those defense measures in multiple places in the network (e.g., TCP stack and/or middle boxes) rather than just one (TLS implementation).

B

---

From: "GUBALLA, JENS (JENS)" <[email-masked]>
Date: Wed, 2 Dec 2015 10:47:06 +0000

> Fortunately the solution is fairly simple: the receiver simply pre-
> computes and keeps in a small hash table the encrypted sequence numbers
> of all packets with sequence numbers between H-W and H+W, where H is
> the highest sequence number correctly received so far (the horizon) and
> W is the anti-replay window size as specified in 4.1.2.5 of RFC 4347,
> which typically should be 32 or 64 according to the RFC.  The receiver
> can precompute all these encryptions because in my proposal TLS headers
> are encrypted with a stream cipher (or the AEAD operating as a stream
> cipher), so it's just a matter of producing the correct cipherstream
> bytes and XORing them with the uint48 sequence number.
> 
> integrity-check.  In the low-probability event of a hash-table
> collision (i.e., two uint48 sequence numbers encrypting to the same 48-
> bit ciphertext in a single 129-datagram window), the receiver can
> trial-decrypt with both (or all) sequence numbers in that colliding
> hash table entry.  Or the receiver can keep it even simpler and just
> drop all but one colliding entry, introducing a pretty low probability
> of introducing occasional "false packet drops."
> 
> even bother clearing/removing old entries; just gradually overwrite
> them with new ones as H moves forward.

[JG] In case there is a packet loss of at least W subsequent DTLS records: 
How can the receiver then ever adjust its hash table? Wouldn't that mean 
that no records at all would be accepted anymore?

Best regards,
Jens

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 11:38:42 +0000

On 12/1/15, Yoav Nir <[email-masked]> wrote:
> Firewall, IPS/IDS devices. Boxes that attempt to perform sanity-check on
> protocols to make sure that the stuff going over TCP port 443 is really
> HTTPS rather than an attempt at tunneling.  There are some attacks such the
> the code that protects against them needs to follow TLS record sizes. For
> the most part these are not-so-interesting attacks, causing certain versions
> of certain browsers to hang, and they are expensive for the firewall to
> protect against, so for the most part these protections are turned off. But
> it’s not everywhere.

Could you be more specific? Which devices are we saying will break? Do
you have model numbers? Are those vendors on this list? Do they agree
that this will break and do we agree that they are a relevant
stakeholder who has a user's security in mind?

For example, do we really care what sandvine or xkeyscore or narus or
similar vendors think? I think the answer is no. They're still going
to do extremely powerful traffic analysis and the more information TLS
leaks, the more they will use it to degrade the security of TLS for
all users. It may be that they will be full, on path, attackers and
yes, in some cases, they can do different more powerful attacks.
Again, we should treat that as a negative thing and make it as hard as
is possible.

>
> If enough middleboxes block TLS 1.3, the browsers will implement a downgrade
> dance. If they do that, attackers will be able to exploit the downgrade
> dance. I don’t think the net effect is better security. We’d be far better
> off writing a separate document on how to use the padding feature that is
> already in 1.3 to mitigate traffic analysis without actually flooding your
> Internet connection. Splitting records and padding a few can be more
> effective than masking the length bits.

Censors are going to perform surveillance and then censor; TLS 1.3
should treat surveillance as a security issue and censorship as an
attack. It may be that we can't stop certain kinds of on path attacks
but man on the side seems nearly entirely do-able. I mean aside from
the TCP reset issues do to layer violation concerns. At least we'll
have DTLS, which won't suffer from such a trivial denial of service...
right?

All the best,
Jacob

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2015 13:59:52 +0200

> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum <[email-masked]> wrote:
> 

I am no expert on middleboxes. I know a little about those that my employer (Check Point) makes. I only know a little, because I’m on the VPN side of things, not the IDS/IPS/next generation firewall side. These are corporate firewalls. When it comes to filtering HTTPS connections, firewalls have three ways to classify the connection:
 1. Look at the SYN and SYN-ACK packets. Make decisions by IP addresses.
 2. #1, and additionally follow the stream looking for certain patterns.
 3. Full “TLS proxy”.

Each of these is “heavier” in amount of resources that it consumes and in the amount of breakage that it might introduce than the one before it, so you only use a higher-numbered way if the lower-numbered way does not give you the results you need. Specifically for #2 which is the one we’re concerned about, there are very few attacks that can be detected by #2 that cannot be detected by #1. I asked someone who does work on these “protections” as we call them, and she told me that only two or three protections require following the stream that do not require proxying, and those were turned off in the default and recommended profiles. So at least with a Check Point firewall, mostly you would not get breakage if record lengths were encrypted, but someone making a client or a server cannot assume that all paths will be free from such inspection. Also, there are many firewall vendors and one is installed in most corporate environments.

So at least one vendor is listening in on this list, and I have a good hunch that at least Cisco, Blue Coat and several others are on this list as well. Whether they are relevant stakeholders or not is to me the same question as whether the network administrator in a corporate environment is a relevant stakeholder. We just make the middlebox that they deploy. 

> have DTLS, which won't suffer from such a trivial denial of service...

Or just use IPsec (I did say I’m no that side of the building…)

Yoav

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 12:38:54 +0000

On 12/2/15, Peter Gutmann <[email-masked]> wrote:
> Why would XKeyscore have trouble with it?

My point was that we're hearing a lot of concern trolling for vendors
and the only "vendor" that has been explicitly named is XKeyscore: a
"vendor" that is without a doubt one that we want to protect against.

> Standard off-the-shelf routers,
> not
> the router.

Absolutely and this proposal will do nothing to change that for on
path TLS 1.3 with TCP and probably for TLS 1.3 DTLS.

>  Encrypting the headers is, at best, a minor speedbump to

If they are only a partial observer, I think Bryan's suggestion
changes the game for TLS and DTLS to leak less information. If they
are a full on path observer, they will have the full leaks of
information made possible from TCP. Thus when composed with an
anonymizing service, we'll find that these changes contribute to a
full solution.

> 4. Provide guidance for TLS and SSH developers on how they can implement

A global passive adversary with a partial view is already harmed by
the changes that have been proposed. A global active adversary with a
partial view would be stymied too.

Bryan has already said it in the thread and replied but I'll agree
with him: we've done it and you're seemingly ignoring it. Furthermore
some people are concerned about surveillance vendors that are not
*opt-in* by the user - rather than treating that concern as abstract,
I'd like to see what specific vendors we should help to weaken the
security properties of TLS 1.3.

> creates for implementers.

I think this is better left in the part of the thread where Bryan
responded - so I'll follow up there next.

> more than "people wanking around with their opinions" (and yeah, that

It is not an opinion that TLS is a metadata leaking protocol and it is
seems that Bryan has found a way to reduce that leakage. With DTLS and
UDP - a surveillance vendor will have very little metadata
comparatively once Bryan's solution is part of the spec.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 12:59:12 +0000

On 12/2/15, Yoav Nir <[email-masked]> wrote:
> I am no expert on middleboxes. I know a little about those that my employer
> (Check Point) makes. I only know a little, because I’m on the VPN side of
> things, not the IDS/IPS/next generation firewall side.

I don't think we should worry about breaking poor little Check Point's
traffic analysis devices. Allow me to shift the overton window: their
device is a problem and we should treat it as a problem on the
network. TLS should mitigate as many of the advantages that they use
to harm end users. We should make those devices use as much RAM and as
much disk space and as much CPU time as possible. In the words of a
Google engineer who discovered the NSA had been doing traffic analysis
on his backbone...

> These are corporate
> firewalls. When it comes to filtering HTTPS connections, firewalls have
> three ways to classify the connection:
> Each of these is “heavier” in amount of resources that it consumes and in
> the amount of breakage that it might introduce than the one before it, so
> you only use a higher-numbered way if the lower-numbered way does not give
> you the results you need. Specifically for #2 which is the one we’re
> concerned about, there are very few attacks that can be detected by #2 that
> cannot be detected by #1. I asked someone who does work on these
> “protections” as we call them, and she told me that only two or three
> protections require following the stream that do not require proxying, and
> those were turned off in the default and recommended profiles. So at least
> with a Check Point firewall, mostly you would not get breakage if record
> lengths were encrypted, but someone making a client or a server cannot
> assume that all paths will be free from such inspection. Also, there are
> many firewall vendors and one is installed in most corporate environments.

That sounds like you're saying that the vendor you represent won't
have issues and that it isn't a problem. Unless I misunderstand,
you're claiming a concern and you've just cleared up that concern. So
we can move on with Bryan's proposal?

> So at least one vendor is listening in on this list, and I have a good hunch
> that at least Cisco, Blue Coat and several others are on this list as well.

I'd love for Blue Coat to step up and talk about how this is similarly
not a problem or how it is a problem for their illegal surveillance
business in Syria, where they've been caught selling surveillance and
censorship gear. I suspect they won't say much but we can hope, right?

> Whether they are relevant stakeholders or not is to me the same question as
> whether the network administrator in a corporate environment is a relevant
> stakeholder. We just make the middlebox that they deploy.

That is a kind of goal post shifting but seeminly weirdly not
relevant, if I understand. If it won't trouble the middle box, it
doesn't sound like the network administrator will have troubles.

It will however reduce off-path reassembly to technique #1 from above
and #2 will be partially eliminated and #3 isn't an option for that
attacker anyway.

We are working on solutions to #1, TLS 1.3 should reduce and if
possible, eliminate #2, and #3 is something that should require
consent of the user in question. Without consent, TLS 1.3 should hard
fail closed as a security measure.

> Or just use IPsec (I did say I’m no that side of the building…)

How well will IPsec deal with such an adversary? I think it is
instructive at all the ways that a protocol won't compose cleanly with
something like Tor, as well as how many distingusihers exist for
technique #2 above. It is very frustrating because yes, it would be
nice if we could just use IPsec. That is however nearly a total lost
cause with regard to surveillance and censorship issues. I once talked
to a Narus vendor who made some amazing claims about traffic analysis
on IPsec - I'll try to dig up some documents.

All the best,
Jacob

---

From: Hubert Kario <[email-masked]>
Date: Wed, 02 Dec 2015 14:33:13 +0100

On Wednesday 02 December 2015 12:59:12 Jacob Appelbaum wrote:
> >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum <[email-masked]>
> >> wrote:>> 
> >>> Firewall, IPS/IDS devices. Boxes that attempt to perform
> >>> sanity-check on protocols to make sure that the stuff going over
> >>> TCP port 443 is really HTTPS rather than an attempt at tunneling.
> >>>  There are some attacks such the
> >>> the code that protects against them needs to follow TLS record
> >>> sizes.
> >>> For
> >>> the most part these are not-so-interesting attacks, causing
> >>> certain
> >>> versions
> >>> of certain browsers to hang, and they are expensive for the
> >>> firewall to protect against, so for the most part these
> >>> protections are turned off. But
> >>> it’s not everywhere.
> >> 
> >> Could you be more specific? Which devices are we saying will break?
> >> Do you have model numbers? Are those vendors on this list? Do they
> >> agree that this will break and do we agree that they are a
> >> relevant stakeholder who has a user's security in mind?
> > 
> > I am no expert on middleboxes. I know a little about those that my
> > employer (Check Point) makes. I only know a little, because I’m on
> > the VPN side of things, not the IDS/IPS/next generation firewall
> > side.
> 
> to harm end users. We should make those devices use as much RAM and
> as much disk space and as much CPU time as possible. In the words of
> a Google engineer who discovered the NSA had been doing traffic
> analysis on his backbone...

Problem is that users care for the cat macros and wedding pictures on 
their social network of choice. If the old version of browser works or 
an other browser works then it /obviously/ is the new browsers fault 
that the connection fails so it's the /new/ browser that is broken.

So the browser vendor implements out-of-protocol fallback to old 
protocol version so that it continues to work. That's a Bad Thing.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Dec 2015 15:38:22 +0200

> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum <[email-masked]> wrote:
> 
> 
>> These are corporate

To be clear, I don’t represent anybody. If I did, I would have to clear this mailing list message with a corporate lawyer and PR department.

I don’t think Bryan’s proposal will hurt the capabilities of a Check Point firewall, and it will make life difficult for me as a developer no more than it will make life difficult for developers of OpenSSL, NSS, SChannel, or any of a dozen other TLS implementations. I don’t know about the other IDS/IPS/Firewall devices.

> censorship gear. I suspect they won't say much but we can hope, right?

I suspect that the Blue Coat people on this list do not represent their employer either.

> fail closed as a security measure.

A TLS proxy requires user consent (or at least device administrator consent) with TLS 1.2. TLS 1.3 does not change that.

> on IPsec - I'll try to dig up some documents.

IPsec has had a lightly-implemented TFC feature since RFC 4301. Without it a packet of IPsec is the same size as the original plaintext packet + a constant overhead rounded up to 4 bytes. So you could do as much traffic analysis on non-TFC IPsec as you could on the plaintext.

Yoav

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 06:12:43 -0800

On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir <[email-masked]> wrote:
>
> I don’t think Bryan’s proposal will hurt the capabilities of a Check Point
> firewall, and it will make life difficult for me as a developer no more
> than it will make life difficult for developers of OpenSSL, NSS, SChannel,
> or any of a dozen other TLS implementations. I don’t know about the other
> IDS/IPS/Firewall devices.
>

The people who will be inconvenienced (if any) by changing the record
framing in an
externally visible way are not largely developers of middleboxes or stacks
but
rather (1) users and (2) client vendors and (3) server operators, who have
to
deal with connections being arbitrarily broken and/or damaged by inspection
devices which expect to be able to observe packet framing.

In Seattle, when the topic of stripping off the fixed three bytes of the
record
header came up (which would have had a similar impact), we agreed to defer
it until we had measurements for the level of breakage that it would cause
(an experiment which we at Mozilla are on the hook for). It seems to me that
this question should be handled similarly.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 06:36:34 -0800

On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford <[email-masked]> wrote:

> That type of inefficiency is extremely easy to avoid; please read the rest
> of my proposal where I discussed exactly that at length.  Yes, a
> particularly stupid implementation could send everything in bursts of two
> packets, but it’s ridiculously easy for a slightly smarter implementation
> to avoid doing that.  And what you’ve gained is complete encryption and
> integrity-checking of the whole TLS record before any part is interpreted,
> which seems like a nontrivial security improvement.

It's not really clear to me what the anti-traffic-analysis benefit of your
proposal
is over and above just padding everything to a fixed size. That's certainly
far
easier for the implementation to do, especially in typical stacks where the
application just calls SSL_Write (or whatever) and so there's no obvious
API point to provide the "next length", so as a practical matter the stack
will very often if not always be in "last block" mode.

The primary security improvement of your proposal seems to be that an
active attacker can't generate a packet header that will put the TLS
implementation in a deadlock state where it's waiting for more data that
will never come. This seems of modest value in TLS [0] given that the
attacker
can cause the connection to be torn down by modifying any packet.
I agree, that this is not exactly the same as leaving the connection
deadlocked
but it still effectively breaks the connection. In addition, I'm not an
expert on TCP internals, but can't you also cause a similar deadlock by
removing a TCP segment sent to the receiver and then ACKing it to the
sender so that there is a gap in the TCP stream?

-Ekr

[0] This issue doesn't apply to DTLS because the stack will just move onto
the next UDP datagram.

---

From: Mike Copley <[email-masked]>
Date: Wed, 2 Dec 2015 15:14:56 +0000

> A TLS proxy requires user consent (or at least device administrator consent) with TLS 1.2. TLS 1.3 does not change that.

With SNI it’s possible to operate a transparent TLS proxy without the users consent. The proxy only has visibility of the SNI hostname - no user data (source: the company I work develops routers with such a proxy). It’s quite useful in hotspot/public wifi environments where making policy decisions based on hostname is more than sufficient, and explicit user configuration of proxy settings is a non-starter. As long as the SNI data is still available in the clear, encrypting subsequent headers won't impact the ability for our particular proxy to operate, as it’s just a generic TCP relay agent at that point.

With all that being said, I think the concerns about length hiding are better addressed through other means rather than header encryption. Not sure if this is the right place to consider, but would DTLS 1.3(?) be able to encrypt headers and still handle packet loss and re-ordering? If DTLS needs cleartext headers, would it be better to advise one approach for both protocols?

Regards,

Mike Copley

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 15:34:12 +0000

> will very often if not always be in "last block" mode.

I think that it eliminates all static distinguisher in the protocol
for all data covered by the encryption. That is a fantastically
wonderful benefit.

> sender so that there is a gap in the TCP stream?

Yes, any TLS connection may be broken by TCP's total lack of
confidentiality, integrity or authenticity. It seems that normally
this happens at setup by IP:port blocking or during later transmission
of a selector/distinguisher that triggers an attack (TCP RST or
others). There is good work in this area by David Stainton with his
Honeybadger project - he actually classified and implemented most of
these TCP attacks to help detect QUANTUMINSERT attacks in the wild:

  https://www.noisebridge.net/pipermail/noisebridge-discuss/2015-April/046273.html

> [0] This issue doesn't apply to DTLS because the stack will just move onto

An off-path attacker can't do much with DTLS, if designed correctly.
Especially if they only see some packets - they'd only get the UDP
headers and then the rest should be uniformly distributed random data,
no? An attacker could thus only interfere during setup - which if
they're on path - we can't stop and expect; the PKI should (ha!) help
with this issue. After that point, especially with devices that move
or are otherwise multi-homed, would be able to spray encrypted packets
out to the network with little other than the UDP headers for an
attacker to use.

Bryan's proposal makes things strictly better with regard to a network
attacker - especially a partial view or off-path attacker who can only
inject packets or who require a selector to trigger an attack.
Effectively, an attacker will be forced to shut down the connection at
setup time or to use the layer separation issues with TCP at any
point. The key difference is that they will have the same information
as they did at setup time, which again seems as a strict improvement
over the current status quo.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 15:38:53 +0000

On 12/2/15, Mike Copley <[email-masked]> wrote:
>> A TLS proxy requires user consent (or at least device administrator
>> consent) with TLS 1.2. TLS 1.3 does not change that.
>
> With SNI it’s possible to operate a transparent TLS proxy without the users
> consent. The proxy only has visibility of the SNI hostname - no user data
> (source: the company I work develops routers with such a proxy).

Yes, we use that for a pluggable transport (
https://trac.torproject.org/projects/tor/wiki/doc/meek ) to bypass
such proxies - connect to google.com, use http header to route to
blocked.com, and so on.

> It’s quite
> useful in hotspot/public wifi environments where making policy decisions
> based on hostname is more than sufficient, and explicit user configuration
> of proxy settings is a non-starter.

That is an attack in my book and public hotspots that do MITM are also
a problem that we need to solve. It is partially solved with WISPr
XML, I think. Though everything in this space is awful because it
breaks everything by default while a system thinks it is online.

> As long as the SNI data is still
> available in the clear, encrypting subsequent headers won't impact the
> ability for our particular proxy to operate, as it’s just a generic TCP
> relay agent at that point.

I hope that we'll hide the SNI data by default and I understand that a
discussion about encrypted SNI is currently scheduled for some point
in the future.

> With all that being said, I think the concerns about length hiding are
> better addressed through other means rather than header encryption. Not sure
> if this is the right place to consider, but would DTLS 1.3(?) be able to
> encrypt headers and still handle packet loss and re-ordering? If DTLS needs
> cleartext headers, would it be better to advise one approach for both
> protocols?

I'm pretty sure that encryption is the only way to "hide"  the data we
want to hide...

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 15:40:52 +0000

> devices which expect to be able to observe packet framing.

Those are also exactly the same parties that benefit from the changes.
Other people who benefit are ISPs, who can't log data that encryption
prevents them from seeing, and there are probably others too.

> this question should be handled similarly.

How can it break something that doesn't yet exist and how can we
measure that? o_0

Again, I'm surprised that no one is attacking the crypto design that
Bryan offered...

All the best,
Jacob

---

From: Watson Ladd <[email-masked]>
Date: Wed, 2 Dec 2015 10:45:20 -0500

> for all data covered by the encryption. That is a fantastically

What's a "static distinguisher"? Padding solves this problem as well,
but it also solves problems resulting from TCP segmentation down the
stack, which header encryption doesn't. What does header encryption
offer that padding does not?

Sincerely,
Watson

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2015 15:46:01 +0000

>Again, I'm surprised that no one is attacking the crypto design that Bryan offered...

They are.  Security is about trade-offs, and the questions have been if the benefit is worth the complexity.  People are assuming that it works.

---

From: [email-masked] (Martin Rex)
Date: Wed, 2 Dec 2015 17:08:37 +0100 (CET)

> discussion about encrypted SNI is currently scheduled for some point

Hiding SNI data is completely silly security-wise, and any TLSv1.2
backwards-compatible ClientHello must include a plaintext visible SNI.

So your client will have to know a-priori, out-of-band or be configured
to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello
with cleartext SNI.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Dec 2015 16:38:31 +0000

> breaks everything by default while a system thinks it is online.

There's a WG in the process of being chartered about captive
portals [1], not sure exactly what it'll end up producing, but
that's a place to go if interested in this specific topic.

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-capport/

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 09:33:37 -0800

> for all data covered by the encryption. That is a fantastically

Wouldn't that benefit be equally achieved by simply padding all records
to a fixed length? You could do this with no protocol change and, as I
said, it's far easier for the implementation.

> no?

DTLS records do in fact contain a length field because it's possible to
pack >1 record into a single UDP datagram. In practice, I think that
most stacks do 1:1 except perhaps during the handshake. They also
contain a sequence number to aid in reconstruction (important
in this case because TLS 1.3 uses the sequence number to
form the AEAD nonce).

However, as you suggest, an attacker can't DoS DTLS connections by
injecting a small number of packets because the DTLS stack will just
reject bogus packets.

-Ekr

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 17:53:40 +0000

> backwards-compatible ClientHello must include a plaintext visible SNI.

Not hiding SNI data is completely silly security wise. SNI data is
used by attackers to perform denial of service attacks and to automate
man-in-the-middle attacks.

We have bare keys in TLS that may also be ephemeral - why would we
want to reveal a selector to the network that we know is used for
active attacks against the protocol?

The question for a few people, myself included, is how we might
protect the SNI data in an efficient manner.

> to TLSv1.3-only in order to avoid using a TLSv1.2-compatible ClientHello

I think that is false. One could easily use the "cleartext" SNI field
and insert an encrypted value. A hash of the name would be a simple
example but not a secure example, of course.

To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less
secure and in ways that will only become worse over time. We should
remember that TLS 1.3, while not yet finished or deployed, is a future
legacy protocol. We shouldn't burden the future with the failures of
TLS 1.2 or any other SSL/TLS mistakes of the past.

All the best,
Jacob

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2015 18:00:26 +0000

> I think that is false. One could easily use the "cleartext" SNI field and insert an encrypted value. A hash of the name would be a simple example but not a secure example, of course.

Encrypted SNI doesn't give you the kind of protection you think that it does.  We (me and a colleague) did a pretty thorough analysis that showed this.  It was not a conclusion we expected, or wanted, to reach.   It was presented at the TLS Interim before the IETF in Toronto.  Slides should be online.  (For example, the adversary will know the IP address or might not care about false positives, etc.)

In spite of this, another colleague (Brian Sniffen) came up with a way to do it at the tail end of the Seattle interim.  Encrypt the "true" SNI in the semi-static DH key of a "fronting" site.  And then the front decrypts the true SNI and forwards to the obscured site. Ekr and dkg presented it in Yokohama, but not very well. :)  They're presumably working on something better.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 2 Dec 2015 10:01:42 -0800

On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich <[email-masked]> wrote:

> and insert an encrypted value. A hash of the name would be a simple example
> but not a secure example, of course.
>
> Encrypted SNI doesn't give you the kind of protection you think that it
> does.  We (me and a colleague) did a pretty thorough analysis that showed
> this.  It was not a conclusion we expected, or wanted, to reach.   It was
> presented at the TLS Interim before the IETF in Toronto.  Slides should be
> online.  (For example, the adversary will know the IP address or might not
> care about false positives, etc.)
>
> In spite of this, another colleague (Brian Sniffen) came up with a way to
> do it at the tail end of the Seattle interim.  Encrypt the "true" SNI in
> the semi-static DH key of a "fronting" site.  And then the front decrypts
> the true SNI and forwards to the obscured site. Ekr and dkg presented it in
> Yokohama, but not very well. :)  They're presumably working on something
> better.

Yes, expect an email with a summary of our current thinking in the next
day or so.

-Ekr

_______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 2 Dec 2015 18:11:51 +0000

On 12/2/15, Salz, Rich <[email-masked]> wrote:
>> I think that is false. One could easily use the "cleartext" SNI field and
>> insert an encrypted value. A hash of the name would be a simple example

Without a concrete proposal, I don't think we have any protection. My
thoughts were more about the idea that we would *want* protection of
SNI data - it seems blindingly obvious to me that we want it as we
know SNI is used for attacks in addition to multi-homing tricks.

I'm aware that layer issues make for many layers of selectors for
attack. If we can avoid adding them in TLS, we can also work on
improving things on every level. IP address blocking has the
"collateral freedom" problem, of course.

> In spite of this, another colleague (Brian Sniffen) came up with a way to do
> it at the tail end of the Seattle interim.  Encrypt the "true" SNI in the
> semi-static DH key of a "fronting" site.  And then the front decrypts the
> true SNI and forwards to the obscured site. Ekr and dkg presented it in

I'm certainly interested in reviewing any cryptographic details for a
possible SNI protection scheme. It sounds interesting and am looking
forward to learning more.

All the best,
Jacob

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 2 Dec 2015 18:16:40 +0000

> it seems blindingly obvious to me that we want it

Few things, particularly in the security arena, are blindingly obvious.  If it actually provides no true protection, then it's just as bad as the security theater in US airports.

> If we can avoid adding them in TLS

We're not adding anything as SNI is already in plaintext.  (Precision counts:).  And we have already added numerous important privacy protections to TLS 1.3.

	/r$

---

From: [email-masked] (Martin Rex)
Date: Wed, 2 Dec 2015 19:48:39 +0100 (CET)

> example but not a secure example, of course.

No you can NOT do this (in TLSv1.2 and earlier), because it is entirely
backwards-incompatible.

Server-side SNI can even be implemented completely outside of the TLS
protocol stack (that is how I implemented it).

> secure

That is a myth.

>
> and in ways that will only become worse over time. We should
> legacy protocol.

TLSv1.3 is looking more and more like a future market failure to me,
worse than IPv6.

-Martin

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 2 Dec 2015 21:00:42 +0200

> example but not a secure example, of course.

Furthermore, SNIs have name type, so even the server_name extension
itself could be extended. The length field is 16-bit too...

-Ilari

---

From: Fabrice Gautier <[email-masked]>
Date: Wed, 2 Dec 2015 11:48:47 -0800

> On Dec 2, 2015, at 01:51, Bryan Ford <[email-masked]> wrote:
> 

Well, it's objectively several order of magnitude more complex than the current record framing. 

And I certainly hope than TLS 1.3 is designed with DTLS in mind. 

> In my first proposal, with headers encrypted with a stream cipher (or AEAD used as one), I think this kind of layering should still be quite feasible, with the one caveat that the TLS record parsing layer does indeed need to make one new “call” into the crypto-related code (to get the header) in addition to the one it already does (to pass the body and header to the crypto code for body-decryption and integrity-check).  

That is one big caveat. And you description doesn't really match what I have in mind. 

In particular, currently, record framing and decryption doesn't need to be synchronous and there is no particular requirement for which one call the other.

So a TLS record framing implemented in an OS kernel TCP stack would not "call" into the decryption layer in userland. It would just queue data in its socket buffer and only signal to userland that data is available when a full record is available to be decrypted.

So it just wouldn't be practical to do this at all with your scheme.

> And only on the receive path; the send path seems pretty much unaffected.  This doesn’t seem like a big layering problem to me, but again subjective opinions may vary.
> 
> In my second proposal, with headers fully encrypted and integrity-checked along with the body, I think the opportunity for the clean layering you propose comes back and perhaps gets even better: it’s just that the record writing/parsing now happens *inside* rather than outside the encryption boundary.  In other words, their order is reversed: the sender invokes the record-writing code first, then the AEAD encryption code to encrypt everything (header and data) at once; the receiver flow invokes the AEAD decryption code first to decrypt everything,

For my example above, the second proposal requires that the application layer tell the network stack what the expected size of the next record is. 

For some implementation it may be more efficient as the decryption layer (in the application) knows exactly how much data it needs to read from the socket - whereas today you need to read the header first, then the rest. 
But it still doesn't allow the network stack to - on its own - signal to the application when it received enough data ready to be decrypted.

> then invokes the separately-modularized record parsing code on the already fully decrypted and integrity-checked record content.  This seems even cleaner to me than the current approach, where the record parsing code has to do some (very careful!) parsing of the record before it’s been authenticated,

The current header is so simple there is virtually no risk to get the framing wrong, and nothing really bad happen even if you do get it wrong.

> then invoke decryption, then do some more internal parsing on the decrypted AEAD body (e.g., the encrypted content-type within).
> 
> B

---

From: Dave Garrett <[email-masked]>
Date: Wed, 2 Dec 2015 15:13:49 -0500

> Encrypted SNI doesn't give you the kind of protection you think that it does.  We (me and a colleague) did a pretty thorough analysis that showed this.  It was not a conclusion we expected, or want…

URL from Rich's previous email citing this:
https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view

Please don't brush this argument off in favor of the "obvious" answer that encrypted SNI is helpful. The sad truth is that it's a lot of effort with a lot of risk for virtually no gain. I was quite in favor of encrypted SNI before reading it, and I had to concede the point after. If we can come up with a way to do it easily, ok, but it's not an avenue worth spending too much time on.

Dave

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 2 Dec 2015 23:36:00 +0000

Bryan Ford <[email-masked]> writes:

>We have repeatedly stated several relevant threat models here; you just 
>don’t seem to be accepting them as threat models for some reason. 

That's because they're not actual threat models, just handwringing about
vague, undefined bogeymen.  Yoav Nir has made a good start, although it's
more a wish list than a threat model, or at least a list of desirable 
properties for the system to have.  In crypto terms, it's like stating
"I want my cryptosystem to be IND-CPA".  The threat there is an adversary
being able to encrypt various plaintext messages and being able to 
distinguish them based on the ciphertext.  You can pretty clearly say
that against this threat (stage #1 of my list), you need an IND-CPA
ciphersystem (stage #2).  From there you can decide whether it's worth
doing this, stage #3 (OK, any cryptosystem worth its salt had better be 
IND-CPA, so that's a tautology).

OTOH an IND-CPA cryptosystem isn't necessarily secure against an
adative chosen ciphertext attack, a different type of threat, so you 
need to up the defence to an IND-CCA2 secure system.

Give me an actual threat model of the type(s) illustrated above, write 
down the exact capabilities of the attacker so we know what to
defend against, and then we can disagree on it.

>We have been doing this as well, repeatedly. 

No, you've just been saying "here's my pet idea, TLS should adopt it"
over and over again.  I'm happy to keep saying "it doesn't provide
the protection you seem to think it does, it restricts TLS to only
using AEAD stream ciphers, and it causes serious headaches for
implementations" as often as you keep repeating "here's my pet idea,
we should use it".

Peter.

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 00:52:39 +0000

On 12/2/15, Salz, Rich <[email-masked]> wrote:
> Few things, particularly in the security arena, are blindingly obvious.  If
> it actually provides no true protection, then it's just as bad as the
> security theater in US airports.

It provides protection. Specifically it provides confidentially.

It doesn't solve the fact that the DNS is a privacy violating
nightmare. It doesn't change the fact that the NSA breaks the rules.

> We're not adding anything as SNI is already in plaintext.  (Precision
> counts:).  And we have already added numerous important privacy protections
> to TLS 1.3.

Leaving SNI in the clear ensures that attackers will be able to
selectively block access by name with ngrep and some basic TCP RST
injection. No cryptographic attacks are required and it will be done
by simply looking for an objectionable string. The economics of that
attack are very low. Forcing an attacker to become a global active or
passive adversary and to perform competent traffic analysis is a much
higher economic cost.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 01:01:17 +0000

> No you can NOT do this (in TLSv1.2 and earlier), because it is entirely

If I configure a vhost to respond to a sha1(example.com) and have a
way to visit sha1(example.com) in a browser, I think it doesn't even
break the spec. That doesn't really matter - the point was to suggest
that there are many ways to solve this problem. Assuming a shared key,
we can easily take a field and transform it. There are compelling
reasons to do it and there are active attackers who are exploiting the
lack of confidentiality in TLS.

> protocol stack (that is how I implemented it).

I'm curious - are you saying that if the value was encrypted... it
would become impossible to implement it outside of the TLS protocol
stack? Or is this just an aside?

>> To the point about TLS 1.2 vs TLS 1.3: Legacy clients will be less

Are you asserting that TLS 1.3 will be less secure or equally secure here?

> TLSv1.3 is looking more and more like a future market failure to me,

Without privacy on the internet, I'll see your market and raise you a TCP RST.

All the best,
Jacob

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2015 01:46:34 +0000

> It provides protection. Specifically it provides confidentially.

It is far from clear that the privacy gains anything in the form of practical protection.  Having looked at it, I'm unconvinced.  And I've been a privacy/crypto advocate for a very very long time.

---

From: Eric Mill <[email-masked]>
Date: Wed, 2 Dec 2015 20:54:54 -0500

> nightmare. It doesn't change the fact that the NSA breaks the rules.

And what Don and Rich's analysis is trying to isolate is how much real
protection you get from that level of confidentiality, so that a decision
that weighs all available factors can be made, including the complexity
cost.

It's not just a collective action problem because DNS isn't encrypted too.
Their analysis also looks at what you get when both are encrypted. And
regardless of DNS being encrypted, rainbow-table style reverse lookups of
IP to DNS name are always possible. That doesn't mean encrypted SNI isn't
worth it -- it clearly provides a security attribute (confidentiality) to
an important piece of information.

But it's not enough to drive ahead and say that some attribute outweighs
every other consideration. For example, HSTS' persistence of memory can be
abused as a tracking device:

http://zyan.scripts.mit.edu/sniffly/

And this was known at the time the spec was finalized:

https://tools.ietf.org/html/rfc6797#section-14.9

But HSTS creates security benefits that are well worth the cost of that
tracking potential (which can also be mitigated through preloading). There
are a lot of browsers and communities which use and advocate for HSTS that
might generally balk at creating tracking devices.

I'm not advocating a strong stance on whether encrypted SNI is worth
pursuing, or whether TLS record headers should be encrypted in TLS 1.3. But
it's useful to keep the debate framed in its full context, rather than
narrowing it to a black-and-white discussion over whether a generally good
attribute is good or not.

-- Eric

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 03:38:39 +0000

> https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view

I've read these slides. I'm... at a bit of a loss. The entire slide
deck seems so flippant as to be not worth addressing. It just doesn't
even pass the giggle test.

Though upon reading it, I am struck by two core points:

One is that big companies will be pressured by governments.
Ironically, Akamai isn't one of those as they're willingly in bed with
governments around the world. But I guess as the slides say, the
author isn't speaking on behalf of Akamai. That said - good, I want
governments to have to go to a company rather than to the user - the
company may have a legal team, the user may have hidden or otherwise
protected themselves. Hopefully the company is in a position to do
nothing or will take action to protect the user's basic liberties.

The second is a constant security nihilism. Yeah, a lot of stuff is
broken - so lets acknowledge it bit by bit and then fix it all.

I would encourage everyone to read the slides as the conclusion in the
presentation simply do not follow. If I had been in the audience when
they were presented, I would have been at the microphone objecting.
The idea that this convinced anyone is baffling.

It is clear that privacy concerns exist in many many different
protocols and that many protocols need to be fixed. Many people point
at other protocols as a way to punt on the issue for their own
protocol. The cycle continues and the privacy violations continue
without end.

> Please don't brush this argument off in favor of the "obvious" answer that
> encrypted SNI is helpful. The sad truth is that it's a lot of effort with a
> lot of risk for virtually no gain. I was quite in favor of encrypted SNI
> before reading it, and I had to concede the point after. If we can come up
> with a way to do it easily, ok, but it's not an avenue worth spending too
> much time on.
>

The idea of splitting the world, as the slides do, into three basic
camps (liberal democracy with good traffic analysis, liberal democracy
with bad traffic analysis and horrible dangerous places) is simply not
serious. The idea that our liberal democracies do perfect traffic
analysis and so we should ensure *everyone* including *non-NSA*
attackers can do it for *free* is just bizarre to me. It is incorrect
as a conclusion to do nothing because some people somewhere *may* be
good at traffic analysis. The logic of the slides suggest that raising
the cost from a kid-in-a-cafe to NSA is proof that we shouldn't
bother. Again, the security nihilism monster appears. We should reject
this nihilism and fix the problem.

Encrypted SNI makes sense as it makes traffic analysis harder.
Encrypting DNS queries makes sense too. Composing it with other
systems may or may not make sense. Even when TLS is composed with a
tool to do traffic analysis resistance, the exit node of the
TA-resistance network can still do selective attacks based on SNI. In
that case the DNS is likely to be resolved at a different exit point.
Thus if we want to punt again and say, hey, traffic analysis
resistance is better left to Tor or something else, please consider
that plaintext selectors make Tor's job harder.

These changes make it more expensive and in some cases, it will stop
attackers who would otherwise be able to make an attack happen
undetected. It requires an attacker to spend more money on CPU, memory
and on other resources to do correlation across multiple collection
points.

Kicking the can down the road doesn't even begin to summarize why
leaving SNI unencrypted is incorrect. Metadata is a serious problem
and reducing it whenever possible (eg: we won't fix TCP/IP on the IETF
TLS list), even in liberal democracies, helps to solve the problems we
face from mass surveillance.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 03:49:02 +0000

On 12/3/15, Salz, Rich <[email-masked]> wrote:
> It is far from clear that the privacy gains anything in the form of
> practical protection.  Having looked at it, I'm unconvinced.  And I've been
> a privacy/crypto advocate for a very very long time.
>

I resolve DNS through Tor and so in that case, my TLS connections
often exit over a different circuit. My TLS connection would not
otherwise leak the host I'm requesting if the protocol had a way to
protect that data. It doesn't. The protocol leak is the problem.

All the best,
Jacob

---

From: Martin Thomson <[email-masked]>
Date: Thu, 3 Dec 2015 14:49:19 +1100

There are a lot of inaccuracies in that presentation, so I wouldn't
pin too much on it.

In any case, before we all get too excited about this, there are some
solutions, I've seen a write-up of one of them, but it was a little
hard to follow first time around.  Some of the things that are
described as impossible aren't that hard to fix.  On the flip site, it
doesn't provide a fully general solution.

Expect to see something very soon.  Until then, I don't think that an
in-depth on what isn't even at a straw-man level of detail is that
helpful.  We need details before we can say whether the cost-benefit
makes sense.

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 03:56:20 +0000

> that weighs all available factors can be made, including the complexity

I'm sorry but that analysis is just not a serious and rigorous analysis.

> It's not just a collective action problem because DNS isn't encrypted too.

The conclusion summary is that because there are many problems, we
won't address our part of the problems. The conclusion is that SNI
privacy isn't worth it because those who live in liberal democracies
with poor traffic analysis, well they just don't matter much. Which
is... just... well, as I said above, I just don't take this seriously.

> an important piece of information.

You're now suggesting an attacker that computes rainbow-tables to
arrive a possibility which in itself sounds like a massive improvement
over what was an absolute certainty.

> might generally balk at creating tracking devices.

Yes, tracking with HSTS is a problem and there is work being done to
mitigate that tracking concern.

> attribute is good or not.

Sure and that full context includes RFC 7258: "Pervasive Monitoring Is
an Attack" - something that defines reasonably clearly many of the
concerns I've stated.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 04:01:58 +0000

> There are a lot of inaccuracies in that presentation, so I wouldn't

I'm not pinning too much on it and I was surprised by the amount it
was suggested would win me over. I actually went in thinking that I'd
be crushed and concede; imagine my surprise!

> doesn't provide a fully general solution.

The question up for debate seems to be if we should bother and I think
that yes, we should bother. I spent some time today thinking about
solutions for encrypting not only SNI but also other headers. It isn't
entirely clear how to solve this problem in a few cases - but
especially in the case of a repeated visit or a site that has an HSTS
entry, I can see a few ways to protect the information.

> helpful.  We need details before we can say whether the cost-benefit

Where is the design actually happening? I know a few cryptographers
who are interested in the design process.

All the best,
Jacob

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Dec 2015 04:33:43 +0000

> protect that data. It doesn't. The protocol leak is the problem.

The most compelling argument for SNI encryption I took away from
this thread the cheap opportunity for blocking traffic based on
cleartext SNI.  Of course SNI encryption can't help if the destination
IP address supports one or a very few related domains, but it could
help otherwise.

Of course nation-states willing to play hardball will work-around
the problem, but they are doing that even without encrypted SNI.

[ Those of you on the crypto list will have seen the announcement
  about Kazakhstan mandating a national security certificate which
  must be installed on all customer devices that use the Internet... ]

-- 
	Viktor.

---

From: Bryan A Ford <[email-masked]>
Date: Thu, 3 Dec 2015 09:50:11 +0100

> offer that padding does not?

Once again (for the n'th time in this thread):  Padding is great and we
should encourage implementations to do it, but it may be impractical to
mandate (a) that *every* TLS 1.3 implementation use padding all the
time, and (b) that *every* implementation that does use padding uses the
*same* padded record size as every other TLS implementation.

If TLS 1.3 did mandate that all implementations always pad to the same
standard-defined record length (to echo Viktor Dukhovni, GO ATM! GO ATM!
:) ), then it might be arguably the case that encrypting headers
wouldn't add any further benefit.

But short of that, encrypting TLS headers makes it strictly harder for a
passive adversary - or an active adversary who can only inject but not
block traffic - to distinguish between padded or unpadded TLS 1.3
streams, or to distinguish between TLS 1.3 streams padded to different
block sizes.

In particular, with encrypted records, we get a guarantee that nothing
in the transmitted TCP stream content itself leaks information about the
internal pattern of records, even if it's un-padded or differently
padded from other streams.  The attacker has to use other side-channels
to perform such distinguishing attacks, and other side-channels are
often lower-bandwidth (e.g., the total length of whole streams or bursts
rather than individual records), and/or more noisy (e.g., the lengths
and timings of TCP segments, which may get retimed and/or resegmented by
all sorts of activities both at the endpoints and in the network).

B

---

From: Bryan A Ford <[email-masked]>
Date: Thu, 3 Dec 2015 10:29:12 +0100

> Please don't brush this argument off in favor of the "obvious" answer that encrypted SNI is helpful. The sad truth is that it's a lot of effort with a lot of risk for virtually no gain. I was quite…

I find it darkly amusing that this argument against the usefulness of
encrypted SNI, supported in substantial part by an argument that "1st
world eavesdroppers do TA really well", is being brought up in the
context of a discussion of my proposal to make traffic analysis harder
by encrypting TLS record headers (in combination with other useful
techniques such as padding).

By all means, let's not encrypt SNI because traffic analysis is easy,
and let's not make traffic analysis harder because SNI is unencrypted
anyway! ... or something like that. :/

I completely agree with Jake's arguments against security nihilism.  The
fact that we can't completely and perfectly solve the whole problem all
at once should not prevent us from working on little pieces of the
problem bit by bit and making life incrementally harder for at least
some of the wide diversity of adversaries out there.

B

---

From: Bryan A Ford <[email-masked]>
Date: Thu, 3 Dec 2015 10:35:30 +0100

Hi Mike,

On 12/2/15 4:14 PM, Mike Copley wrote:
> [...] Not sure if this is the right place to consider, but would DTLS 1.3(?) be able to encrypt headers and still handle packet loss and re-ordering? If DTLS needs cleartext headers, would it be better to advise one approach for both protocols?

Please see the other recent E-mails in this discussion thread
specifically addressing how my first proposal extends to DTLS.  My
second proposed approach to header encryption is admittedly more
TCP-specific, and that might be one legitimate reason to prefer the
first one if we care about keeping TLS and DTLS as closely-aligned as
possible.

B

---

From: Bryan A Ford <[email-masked]>
Date: Thu, 3 Dec 2015 10:51:24 +0100

Hi Jens,

> that no records at all would be accepted anymore?

Excellent question - I had intended to discuss that in my original post
but in the end forgot to include it.

Indeed, with this approach as it stands, if every packet within a full
window of W consecutive packets fails to reach the receiver, then the
receiver has no way to resynchronize and the connection will simply
fail.  In congestion-controlled protocols like TCP (or DCCP) that do
exponential backoff when they detect many consecutive losses, the
protocol may be more likely simply to hard-timeout than to reach the
W-packet resynchronization limit.  But admittedly many UDP-based
protocols aren't (or are rather weakly) congestion-controlled, so this
may be more of a problem for them.  It's probably the case that the
"forward-looking window" should be allowed to have a different value
from the "backward-looking window", and perhaps the "forward-looking
window" should depend on RTT (e.g., measured maximum packets-in-flight).

However, one way to eliminate this risk of permanent desynchronization,
at the cost of a bit more complexity in the receiver implementation
(though this needn't affect the protocol spec at all) is for the
receiver's "forward-looking window" to consist not of W consecutive
sequence numbers but a sparse set of sequence numbers at
exponentially-increasing distances.  For example, if H is the current
highest sequence number, include in the forward-looking cache the
encrypted sequence numbers of the sequence number of the next multiple
of 2^1 beyond H, the next multiple of 2^2, etc., for as many multiples
of powers-of-two to get sufficiently far out in the sequence number
space where we're convinced there's no realistic chance of a run of
total or near-total packet loss unless it really means the connection is
dead anyway. :)

Again, these are all considerations that need not affect the protocol
but could be tuned by implementations (perhaps with some recommendations
in the protocol spec).

But regardless, all of this is just to make the case that header
encryption is in principle just as feasible in DTLS as in TLS, and using
fairly similar techniques; right now I think we should keep the main
focus on whether to do it (at least) in TLS, for which is seems pretty
easy to do it in at least two different ways I've proposed.

B

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 11:36:40 +0000

> said, it's far easier for the implementation.

Padding is potentially useful but has two issues that come to mind
which are both non-issues in most cases. The first is the economic
cost for extra bytes and the second is the security of the padding
scheme.

Padding strategies are a complement super encryption but probably not
a replacement. Padding protects against one set of attackers (bean
counters) and super encryption provides confidentiality against
another set of attackers (GPA/APA).

> injecting a small number of packets because the DTLS stack will just

This alone makes me think that DTLS with encrypted record headers is
going to be a killer feature. Especially if an implementation rotates
over ip:port and keeps sessions open even as clients move between
networks. We'll hopefully see clients keyex on one network and keep a
session open as they move to another network. That would make
interception or attacking that client very difficult for an off-path
partial view attacker, as well as very difficult even for a fully
on-path mitm. The downside is that it won't compose very well with
existing anonymity systems. The other other upside is that those
systems can use this mode in the future for client -> network, inter
network communication and network -> everywhere communications.

All the best,
Jacob

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 03 Dec 2015 14:15:10 +0100

Hi *,

> I'm sorry but that analysis is just not a serious and rigorous analysis.

No it's not. It's a very short presentation from a TLS-WG interim
meeting. The threat-model concerns Akamai's (and other's) current and -
possibly - future use of TLS. We're not trying to build an Onion routing
protocol. Given the FUD on the Tor dev list, this is a good thing. While
the presentation might have flaws from the perspective of an Onion
routing protocol developer, it reflects the point of view of a lot of
people/companies on this list, I assume.

> is... just... well, as I said above, I just don't take this seriously.

See above, different point of views on the same problem. I agree here
and think we should continue to find a proper solution for encrypted-SNI
for TLS 1.3 - if at all possible. What we currently have on our hands is
not very convincing to me.

> over what was an absolute certainty.

+1.

> an Attack" - something that defines reasonably clearly many of the

While kind of a political/policy document I agree that IETF WG's should
follow (and participants read) it. I remember the STRINT meeting in 2014
where a lot of people were very pissed about NSA activity and we decided
we want to do something about it. If it takes a standard a few months
longer to be finished, please give it the proper amount of time for
enough people to put their ideas into it. Most people do not come up
with solid engineering solutions over night. And crypto is hard as we
all know. We should not forget that TLS has a very different
threat-model and performance assumptions than Tor though.

Thanks,
Aaron

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 3 Dec 2015 13:22:33 +0000

> I actually went in thinking that I'd be crushed and concede; imagine my surprise!

The fact that you viewed it as "crushed and concede" implies to me that your mind was already made up, and that no description of trade-offs was going to sway you.  Is that belief unfair to you?

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 03 Dec 2015 15:07:43 +0100

PS:

> people/companies on this list, I assume.

I don't think traffic analysis is in the treat model for TLS proper. If
we wanted to circumvent traffic analysis we'd have to introduce noise
and randomness (Pond does a good job there using Tor and other
mechanisms). I don't see how we can engineer a low-latency (now even
0-RTT) network security protocol that will do that in a performant
manner. When time comes and people have 10-40-100GE at home, maybe.
Infiniband would be nice. But that will still leave out use for 3rd
world countries (which still run on XP anyway). This is a technical list
and we should keep politics and FUD aside as best as possible.

Greetings from a very empty Sinai peninsula,
(A)aron

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 15:24:56 +0000

On 12/3/15, Salz, Rich <[email-masked]> wrote:
> The fact that you viewed it as "crushed and concede" implies to me that your
> mind was already made up, and that no description of trade-offs was going to
> sway you.  Is that belief unfair to you?

No, I said explicitly the opposite: I expected that you would change
my mind because you took the time to think about it, write slides and
present it. I'm late to the party, so I had an open mind and was
shocked that this was what had convinced anyone at all.

I'm sympathetic to the government pressure angle but I do not believe
that because one is afraid, one does better by preemptively
capitulating.

If Akamai wants to leave their users insecure, I look forward to
another CDN offering privacy options. Such choice is missing if that
isn't an option and it isn't on as a strong default.

In any case, I await the specific cryptographic details and some of
the people in my cryptographic research group (non-Tor) are
interested. When it is published, I'll see if it actually helps to
solve the problem at hand. If we can't design a cryptographic scheme
to protect SNI, I'd understand fully why we won't have such a
protection deployed. If we design it and then we're unhappy about DNS,
well, great, one problem down - next up, dnsop works to solve the DNS
query privacy problem. There is already work being done there - so I
think we're on the way.

All the best,
Jacob

---

From: Watson Ladd <[email-masked]>
Date: Thu, 3 Dec 2015 10:59:57 -0500

> another set of attackers (GPA/APA).

But as several people have noted, encrypting record lengths doesn't
actually protect the lengths of the records
as well as you think it does. Timing packets is not some exotic and
unavailable technology. I don't understand what
attacks padding and introduction of dummy packets doesn't defend
against that encryption of record lengths does.

Sincerely,
Watson

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 16:04:33 +0000

Hello,

On 12/3/15, Aaron Zauner <[email-masked]> wrote:
> I don't think traffic analysis is in the treat model for TLS proper.

I'm confused by what you mean by traffic analysis. We encrypt content
in TLS because we know that we want confidentiality. We want that
because we know people do basic traffic analysis looking for sensitive
data in plaintext.

There are many kinds of traffic analysis adversaries. I think TLS
isn't trying to beat a global active adversary, for example, while
also providing anonymity. It seems that TLS is trying to beat a global
passive adversary from violating the confidentiality of the protocol.

A lack of confidentiality in many cases allows for attackers to do
better traffic analysis and selective denial of service attacks.
Failure to deal with very simple traffic analysis leads to much more
serious attack vectors being actively exploited in the wild.

>  If

The architecture of the network protocol is the politics. There is no
separation.

RFC1984 and RFC 7258 cover this topic nicely.

All the best,
Jacob

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 16:15:41 +0000

On 12/3/15, Watson Ladd <[email-masked]> wrote:
>>>> >> >> the length of the *current* record but instead indicates the
>>>> >> >> length
>>>> of
>>>> >> >> the *next* record.
>>>> >> >
>>>> >> That type of inefficiency is extremely easy to avoid; please read
>>>> >> the
>>>> >> rest
>>>> >> particularly stupid implementation could send everything in bursts
>>>> >> of
>>>> two
>>>> > easier for the implementation to do, especially in typical stacks
>>>> > where
>>>> the
> as well as you think it does.

I think it protects the length data exactly as much as it does. :-)

It doesn't solve the problem that for a given TCP flow, we'll have a
byte counter, of course. That is also why I'm quite interested in DTLS
with super encryption. Especially with users roaming across networks,
I'm hopeful that we'll blind partial view attackers even more than
ever.

> Timing packets is not some exotic and

We should also ensure that we have padding and dummy packets, of course.

Still I don't see that we'll turn TLS into ATM nor do I believe that
we understand an optimal padding strategy. I think you are correct
that an attacker with a clock and a bean counter is a valid problem. I
also think that the more state we force an attacker to hold, the more
expensive it becomes to perform correlated traffic analysis across
global networks.

Super encryption of records also means that accidents at one layer may
not be as catastrophic at another layer.

All the best,
Jacob

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 03 Dec 2015 17:25:28 +0100

Hey,

> because we know people do basic traffic analysis looking for sensitive

I don't work in SIGINT nor for commercial networking vendors so I always
have used jargon I picked up from Wikipedia:
```
Traffic analysis is the process of intercepting and examining messages
in order to deduce information from patterns in communication. It can be
performed even when the messages are encrypted and cannot be decrypted.
In general, the greater the number of messages observed, or even
intercepted and stored, the more can be inferred from the traffic.
``` -- https://en.wikipedia.org/wiki/Traffic_analysis

My example, Pond, counters this with padding, randomized traffic
patterns and - of course - Tor [0]. I'm just saying this is unpractical
for a low-latency protocol such as TLS. I think we all agree there.

> serious attack vectors being actively exploited in the wild.

See my last message, I'm absolutely for encrypted-SNI. If it's feasible.
If we end up with some compromise, maybe. But what we have now is
nowhere near ideal.

BTW, I played with SNI DoS a few months back (not too much though as it
wasn't worth a paper), seems not to be as bad as it used to be because
implementations nowadays have at least some counter-measures.

> RFC1984 and RFC 7258 cover this topic nicely.

Bashing on random companies won't get us anywhere. I agree with you, but
it's off-topic here. Most of the participants here do not represent
their employer and even though some might have made a bad employment
choice, it's up to them. They mostly speak for themselves and bring
valuable implementer opinion to the table. Some break TLS on a massive
scale and this is a problem (we have a vendor-nickname for a certain TLS
extension after all). See also RFC7624, RFC7696.

Aaron

[0] -  https://pond.imperialviolet.org/tech.html
       (Ctrl+S "traffic profile")

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 03 Dec 2015 17:44:04 +0100

Errata:

> implementations nowadays have at least some counter-measures.

Was supposed to say 'renegotiation DoS' I've looked at SNI as well in
this context.

Aaron

---

From: [email-masked] (Martin Rex)
Date: Thu, 3 Dec 2015 17:53:44 +0100 (CET)

> Are you asserting that TLS 1.3 will be less secure or equally secure here?

Even TLSv1.0 is sufficiently secure already, so that there
are plenty of other attack surfaces *MUCH* easier to attack.

http://www.schneier.com/books/practical_cryptography/preface.html

   Arguing about whether a key should be 112 bits or 128 bits long is
   rather like pounding a huge stake into the ground and hoping the
   attacker runs right into it. You can argue whether the stake should
   be a mile or a mile-and-a-half high, but the attacker is simply going
   to walk around the stake.

If you design anything around TLS where the "secrecy" of the servername
is important, then you are acting extremely irresponsible.  There are so
many ways and places where the servername WILL be leaked, (URLs, bookmarks,
HTTP-Header-Fields,  HTTP-Referer headers, etc.) that bottom line, encrypting
SNI amounts to crazy and pointless idea.

Using sha1(servername) instead of servername is (a) not confidential
and (b) backwards-incompatible with the existing protocol&usage and
the installed base.  No matter how many hoops you jump, encrypting
SNI will never become anything close to a TOR hidden service.
And for the vast majority of servers, there is going to be such
a small number of virtual services, that distinguishing them will
always be trivial by their traffic patterns.  There is nothing that
TLS could do about app-determined traffic patterns of unrelated
TLS sessions.

You could use innocent servernames or multi-SAN server certs plus *NO* SNI.
and both would provide higher security and be much easier to implement
than encrypting SNI.

-Martin

---

From: Jacob Appelbaum <[email-masked]>
Date: Thu, 3 Dec 2015 23:46:40 +0000

>    to walk around the stake.

I look forward to using that poor saps TLS 1.0 services - where TLS
isn't the weakest link!

> SNI amounts to crazy and pointless idea.

Huh - Could you please enumerate all of the places that TLS leaks a
hostname requested by a client? Each one of them is a problem and we
should correct it. TCP/IP and DNS are out of scope, though obviously
related.

> the installed base.

That was not a serious suggestion. If you think that I seriously
suggested hashing the server name, I'm sorry. Please re-read my email
and understand that I was suggesting that we can change the value of a
field easily to make the attack more expensive. To make it worth
doing, we want a better scheme than a straight hash of a name, of
course.

> No matter how many hoops you jump, encrypting

We probably agree here - there is a case where you want to compose
with Tor. However there is a different issue which is that by leaving
the client requested name in the clear, an attacker, even against a
Tor exit node, can denial of service a specific client with nothing
more than a word list. This is no different from HTTP without TLS for
tearing a connection down; it becomes different with TLS 1.2 and DTLS
(and probably with something like Bryan's super encryption). Sadly,
DTLS doesn't compose with Tor and so, we want a similarly hard to
distinguish TCP protocol that does compose with Tor.

None the less - eventually a long term attacker may be able to learn
things about public websites (eg: which wikipedia page you visited) -
for non public websites, I don't believe that you can make the same
claim. Additionally, the bar for an attack has just been seriously
raised from ngrep to a pretty sophisticated attacker with long term
funding.

> and both would provide higher security and be much easier to implement

I look forward to your proposal that removes the need for encrypting
SNI. I think it will be interesting to compare your construction with
the soon to be shown encrypted SNI proposal.

All the best,
Jacob

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 4 Dec 2015 03:03:56 +0000

Jacob Appelbaum <[email-masked]> writes:

>TCP/IP and DNS are out of scope, though obviously related.

Why are they out of scope?  You can't just ignore a threat if it's
inconvenient, you need to look at the overall picture.  Arguing over plugging
a mousehole in the corner of the barn is pointless when two of the four walls
are missing.  As Martin has pointed out:

  There are so many ways and places where the servername WILL be leaked,
  (URLs, bookmarks, HTTP-Header-Fields,  HTTP-Referer headers, etc.) that
  bottom line, encrypting SNI amounts to crazy and pointless idea.

I'm not sure if I'd call it crazy and pointless, just not worthwhile.  You're
leaking server-name information in a great many other locations and ways, and
encrypted SNIs causes so many problems, that the cost/benefit tradeoff doesn't
make it worthwhile (which, I guess, could be classed as "pointless").

Perhaps someone could write an RFC for a play-with-experimental-features TLS
extension, where implementers could encrypt lengths and SNIs and anything else
they want, and then test them out in the real world to see what effect it has.

Peter.

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 4 Dec 2015 03:50:36 +0000

On 12/4/15, Peter Gutmann <[email-masked]> wrote:
> Why are they out of scope?

They are out of scope for the TLS working group as far as I understand
the organization of the IETF in terms of mandate. Am I incorrect?
Should we discuss the privacy failures of IPv6 on this list as well?
I'm happy to do so but I think this is out of scope.

> You can't just ignore a threat if it's
> inconvenient, you need to look at the overall picture.

That is exactly what I've been saying over the last several days and
really for many years. The collective action failures here are not
because I can't see the overall picture but because there is blame
shifting. If we look at one specific protocol and solve things, we
find that composed with other solutions, we're really working toward
an overall solution.

> Arguing over
> plugging

TLS protects the HTTP headers, bookmarks don't travel across the
network and a url needs to be sent by a protocol to be leaked to the
network. The client requested hostname is leaked a single time.
Plugging that leak by encrypting it is not impossible and that someone
might share a URL doesn't mitigate the usefulness of reducing that
specific information leakage in TLS.

The point is not to hide that a server has a name - the point is to
protect a flow within a relevant time frame. This may prevent an
adversary from selecting it for storage (ex: XKeyscore selector on
cs.auckland.ac.nz) or it may prevent an adversary from doing an active
attack from even as lowly as an off-path position having seen just a
single or small subset of packets from a given flow. There are other
reasons as well.

That DNS has problems doesn't mitigate that TLS itself has problems
when it stands alone.

> make it worthwhile (which, I guess, could be classed as "pointless").

As a TLS user - I'm only leaking SNI at Tor exit nodes and there is no
other choice for me. I'm living in the world where DNS and other
channels are not leaking on the same path as my TLS connection. Still,
my TLS connections have a lot of information that is available to a
sniffer on a Tor exit or XKeyscore on the whole internet. Removal of
the SNI field is not an option - encrypting it should be an option, if
not a strong default.

> they want, and then test them out in the real world to see what effect it

Or they could just call MinimaLT or CurveCP with mandatory Elligator
TLS 1.3 and be done with it.

All the best,
Jacob

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Dec 2015 09:56:29 +0300

Hi Bryan,

I guess Dmitry is talking about the trick when each datagram is encrypted with its own key, 
derived from the "master" session key using some unique public parameter of the datagram,
like its sequence_number. This trick makes attacks on encryption key almost useless.
It is not specifically bound to GOST cipher, however it is sometimes used with this cipher 
to deal with its short (by current standards) block size. See for example the (now expired) draft 
https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt
(it is about ESP, but the general principles are the same for DTLS).

As far as I understand your proposal makes impossible to use this trick, 
if we consider packets loss and reordering.

Regards,
Valery Smyslov.

  From: Bryan Ford 
  To: Dmitry Belyavsky 
  Cc: [email-masked] 
  Sent: Wednesday, December 02, 2015 12:11 PM
  Subject: Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

  B

    -- 

    SY, Dmitry Belyavsky

------------------------------------------------------------------------------

---

From: Bryan Ford <[email-masked]>
Date: Fri, 4 Dec 2015 11:17:21 +0100

On 04 Dec 2015, at 07:56, Valery Smyslov <[email-masked]> wrote:
> https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt <https://www.ietf.org/archive/id/draft-fedchenko-ipsecme-cpesp-gost-04.txt>

Ah, I see - thanks for the clarification.

> if we consider packets loss and reordering.

Actually, if I’m understanding correctly how you’re doing this per-datagram rekeying, I think it still should be compatible with the hash-table-based approach I proposed.  Assuming you’re using some key derivation function that takes a master key and sequence number as input and produces a per-datagram key, the receiver just needs to pre-compute the per-datagram keys for the sequence numbers within the current window, and encrypt the sequence numbers with those respective per-datagram keys, in order to populate its hash table.  I don’t think anything breaks at least.

Cheers
Bryan

---

From: "GUBALLA, JENS (JENS)" <[email-masked]>
Date: Fri, 4 Dec 2015 12:52:17 +0000

Hi Brian,

> -----Original Message-----
> From: Bryan A Ford [mailto:[email-masked]]
> Sent: Donnerstag, 3. Dezember 2015 10:51
> To: GUBALLA, JENS (JENS); Fabrice Gautier
> Cc: [email-masked]
> Subject: Re: [TLS] Encrypting record headers: practical for TLS 1.3
> after all?
> 
> Hi Jens,
> 
[JG] That would mean legitimate records would be dropped until an entry in
the hash would match. Thus this proposal would potentially degrade the
service, right?

Basically I fail to see how a stream cipher can be operated reliable on top
of an unreliable transport protocol.

Best regards,
Jens

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 4 Dec 2015 15:57:27 +0300

Actually, if I’m understanding correctly how you’re doing this per-datagram rekeying, I think it still should be compatible with the hash-table-based approach I proposed.  Assuming you’re using some key derivation function that takes a master key and sequence number as input and produces a per-datagram key, the receiver just needs to pre-compute the per-datagram keys for the sequence numbers within the current window, and encrypt the sequence numbers with those respective per-datagram keys, in order to populate its hash table.  I don’t think anything breaks at least.
I would say that the hash-table-based approach would work in theory.
In practice it either implies too much burden on the receiver or would fail
in some situations. Consider, for example, situation when the sender 
skips large amount of sequence numbers (say 2^32) for some reason.
It would be difficult for receiver to build such a hash table.

Regards,
Valery Smyslov.

---

From: Jacob Appelbaum <[email-masked]>
Date: Fri, 4 Dec 2015 15:39:13 +0000

On 12/2/15, Watson Ladd <[email-masked]> wrote:
> On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum <[email-masked]>
>>

Fixed parts of a protocol are often considered as static
distinguishers - most are unavoidable unless you take the Scramblesuit
design approach and have a keyexchanged out of band. Elligator is
another useful design in this direction.

In the case of TLS, we've seen a specific Oakley group used as the
distinguisher that selected all related (TCP) flows for disruption.
Changing that to a (well formed) randomly selected value allowed
traffic to flow freely again. Other static values like a site specific
plaintext name are used much more commonly.

I could imagine for example that all records with a given length can
be selected and dropped, for example. Common VoIP applications that
use fixed lengths are thus even easier to censor with an exposed
length field. With that value hidden and with *random* padding, I
think the ease of selecting specific flows would be reduced and the
cost would be much higher. No everyone needs padding but many people
will want that value hidden without a useful way to do it unless the
protocol supports it by default.

All the best,
Jacob

---

From: Jeff Burdges <[email-masked]>
Date: Fri, 04 Dec 2015 17:22:06 +0100

Bryan Ford <[email-masked]> wrote : 
> 2. The 2-byte length field in each record's header no longer 
> indicates the length of the *current* record but instead indicates
> the length of the *next* record.  The length of the first record
> might be defined in a new field we add to the handshake/key-exchange
> protocol, or it might simply be set to some well-known standard first
> record size.

Using a standard size for the first message sounds like an amazingly
good idea, irrespective of whether the idea of each message containing
the next message's size works out.  Any thoughts on how big this first
message should be? 

Jeff

---

From: Peter Gutmann <[email-masked]>
Date: Sun, 6 Dec 2015 00:01:09 +0000

Jacob Appelbaum <[email-masked]> writes:

>They are out of scope for the TLS working group as far as I understand the
>organization of the IETF in terms of mandate. Am I incorrect?

They're out of scope in that TLS can't impose behaviour on DNS, but they're
not out of scope when it comes to considering what impact DNS has on TLS.  For
example the whole reason why TLS has certificates is because the TLS (well,
SSL then) folks realised that DNS wasn't secure, and that TLS had to deal with
that issue.  Otherwise, the SSL folks could have just said that DNS issues are
out of scope, and we'll wait for DNSSEC to appear at some point and fix things
(this is speaking from a 1995 time frame).

>Or they could just call MinimaLT or CurveCP with mandatory Elligator TLS 1.3
>and be done with it.

That would probably be an easier process than the current one, provided you're
ready to commit completely to the Bernstein monoculture.

Peter.

---

From: Jacob Appelbaum <[email-masked]>
Date: Sun, 6 Dec 2015 01:52:44 +0000

On 12/6/15, Peter Gutmann <[email-masked]> wrote:
> not out of scope when it comes to considering what impact DNS has on TLS.

Of course. Thankfully there is work to fix DNS by... using TLS!

> (this is speaking from a 1995 time frame).

Hopefully someday, we'll have the DNS security problem solved. Until
then, I look forward to the TLS working group to not making name
privacy _harder_ to implement. The great irony of DNS potentially
using TLS for privacy is... oh, so much for that strategy.

> ready to commit completely to the Bernstein monoculture.

I admit, I'm biased here. I'd rather have a monoculture of security
than polyculture of insecurely designed by commitee.

All the best,
Jacob