Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Dmitry Belyavsky]

Dear Bryan,

On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford  wrote:

> Hi Dmitry,
>
> On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> > Dear Bryan,
> >
> > 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.
> >
> >
> > 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Bryan Ford]

On 02 Dec 2015, at 06:02, Martin Thomson  wrote:
> On 1 December 2015 at 08:22, Bryan A Ford  wrote:
>> 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.
> 
> 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).

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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Bryan Ford]

On 02 Dec 2015, at 09:42, Dmitry Belyavsky  wrote:
> On Wed, Dec 2, 2015 at 12:45 AM, Bryan A Ford  > wrote:
> On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> > Dear Bryan,
> >
> > 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.
> >
> >
> > 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.
> 
> 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. 

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

> 
> 
> -- 
> SY, Dmitry Belyavsky



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bryan Ford]

On 02 Dec 2015, at 00:54, Fabrice Gautier  wrote:
> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford  > wrote:
>> 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. […]
> 
> Hum I wouldn't qualify this as a "fairly simple" solution.

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

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

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

smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Bryan Ford]

On 02 Dec 2015, at 02:24, Peter Gutmann  wrote:
> Jacob Appelbaum  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).

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.

> 2. List the various measures that can be used to defend against the threat:
>   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

smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fresh results

[Nikos Mavrogiannopoulos]

On Tue, 2015-12-01 at 21:02 +0100, Hanno Böck wrote:
> On Tue, 1 Dec 2015 14:28:49 -0500
> Watson Ladd  wrote:
> 
> > https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls
> > 13QuicAttacks.pdf
> > 
> > This one looks very nasty to fix. Short of disallowing the use of
> > RSA
> > certificates for TLS 1.2 with the RSA handshake and in TLS 1.3, I
> > don't see a good fix. I haven't read this paper in detail yet.
> > 
> > Cross-protocol attacks are the gift that keeps giving.
> 
> Correct me if I'm wrong, but as I understand the result (and I had
> one
> of the authors explaining it to me a few days ago) the problem
> appears
> only if you have a TLS 1.2 implementation with an RSA keyexchange
> that
> is vulnerable to a bleichenbacher attack. If it is not then you're
> fine.

The interesting result of the paper is:
"Even though this limits the
practical  impact  of  this  attack,  it  demonstrates  that  simply
removing a legacy algorithm from a standard is not necessarily
sufficient to protect against its weaknesses."

Even though the attack does not work for current implementations it
underlines that if you reuse keys from TLS 1.2 to TLS 1.3 you don't get
any advantage from the better algorithms in TLS 1.3. You are as safe,
as if you'd be using TLS 1.2.

That can be claimed to be trivial result given that it is underlined on
almost every paper that describes a cross-protocol attack, but it is
not still grasped by the engineering community. There have been
described quite some cross protocol attacks (Kerberos 4 -> Kerberos 5
by Yu et al., TLS between ciphersuites starting by Wagner and
Schneier), but still we reuse keys between protocols.

regards,
Nikos

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

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

[GUBALLA, JENS (JENS)]

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

[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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jacob Appelbaum]

On 12/1/15, Yoav Nir  wrote:
>
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum  wrote:
>>
>> On 12/1/15, Viktor Dukhovni  wrote:
>>> On Mon, Nov 30, 2015 at 10:34:27AM +, Peter Gutmann wrote:
>>>
 Bryan A Ford  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.

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

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

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

[Yoav Nir]

> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum  wrote:
> 
> On 12/1/15, Yoav Nir  wrote:
>> 
>>> 
>>> 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.
> 
> 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. 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. 

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

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

Yoav

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

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

[Jacob Appelbaum]

On 12/2/15, Peter Gutmann  wrote:
> Jacob Appelbaum  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?

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
> even specialised USG surveillance gear, does fairly sophisticated flow
> tracing, packet reassembly, connection analysis, and so on.  It's built into
> 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
> 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 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.

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

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.

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

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

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

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

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

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

[Jacob Appelbaum]

On 12/2/15, Yoav Nir  wrote:
>
>> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum  wrote:
>>
>> On 12/1/15, Yoav Nir  wrote:
>>>

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

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

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.

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

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

[Hubert Kario]

On Wednesday 02 December 2015 12:59:12 Jacob Appelbaum wrote:
> On 12/2/15, Yoav Nir  wrote:
> >> On 2 Dec 2015, at 1:38 PM, Jacob Appelbaum 
> >> wrote:>> 
> >> On 12/1/15, Yoav Nir  wrote:
>  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.
> >> 
> >> 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.
> 
> 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...

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

signature.asc
Description: This is a digitally signed message part.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yoav Nir]

> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum  wrote:
> 
> 
>> 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.
> 
> 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?

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.

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

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

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

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

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

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

[Eric Rescorla]

On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir  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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Eric Rescorla]

On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford  wrote:

> On 02 Dec 2015, at 06:02, Martin Thomson  wrote:
> > On 1 December 2015 at 08:22, Bryan A Ford  wrote:
> >> 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.
> >
> > 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).
>
> 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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Mike Copley]

On 2/12/2015, at 1:38 pm, Yoav Nir  wrote:

> 
>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum  wrote:
>> 
>> 
>>> 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”.
> 
>>> 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.
> 
> 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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Jacob Appelbaum]

On 12/2/15, Eric Rescorla  wrote:
> On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford  wrote:
>
>> On 02 Dec 2015, at 06:02, Martin Thomson 
>> wrote:
>> > On 1 December 2015 at 08:22, Bryan A Ford 
>> > wrote:
>> >> 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.
>> >
>> > 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).
>>
>> 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.
>

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

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

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

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

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

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

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

[Jacob Appelbaum]

On 12/2/15, Mike Copley  wrote:
>
> On 2/12/2015, at 1:38 pm, Yoav Nir  wrote:
>
>>
>>> On 2 Dec 2015, at 2:59 PM, Jacob Appelbaum  wrote:
>>>
>>>
 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”.
>>
 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.
>>
>> 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

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

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

[Jacob Appelbaum]

On 12/2/15, Eric Rescorla  wrote:
> On Wed, Dec 2, 2015 at 5:38 AM, Yoav Nir  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.

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.

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

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

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

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Watson Ladd]

On Wed, Dec 2, 2015 at 10:34 AM, Jacob Appelbaum  wrote:
> On 12/2/15, Eric Rescorla  wrote:
>> On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford  wrote:
>>
>>> On 02 Dec 2015, at 06:02, Martin Thomson 
>>> wrote:
>>> > On 1 December 2015 at 08:22, Bryan A Ford 
>>> > wrote:
>>> >> 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.
>>> >
>>> > 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).
>>>
>>> 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.
>>
>
> I think that it eliminates all static distinguisher in the protocol
> for all data covered by the encryption. That is a fantastically
> wonderful benefit.

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.

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

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

[Salz, Rich]

>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.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Martin Rex]

Jacob Appelbaum wrote:
> 
> 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.

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

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

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

[Stephen Farrell]

On 02/12/15 15:38, Jacob Appelbaum wrote:
>> > 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.
> 

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/

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

Re: [TLS] Draft status and updates

[Ilari Liusvaara]

On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> 
> 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> are jointly used to produce the traffic keys and also to form a MAC over
> the handshake. As Hugo pointed out originally, this alone should
> be sufficient to authenticate the server's side of the connection and
> you could omit the server CertificateVerify (Hugo, please correct
> me if I have misunderstood).

Is it guaranteed that the groups are the same?

Even if it is, due to implementation bugs, bad idea to rely upon that.
 
> Trying to read between the lines, is your concern that the server is
> now no longer explicitly signing over the ServerConfiguration in
> its CertificateVerify [Note that the client continues to do so]? The idea
> behind removing that was to make the 1-RTT part of the handshake
> more uniform regardless of whether 0-RTT data was used.
> I'm certainly open to putting that back in if it's needed, but can you
> explain your concern in more detail?

The concern is that attacker that has managed to inject g^s for
known s is able to impersonate the server even through server certificate
validation on subsequent connections (under some conditions).

(Indirectly) signing g^s would prevent this.

... Funkily enough, this attack doesn't work against either tls-unique
nor tls-extractor (however, those still fail nonce check with respect
to SS)...



-Ilari

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

Re: [TLS] Draft status and updates

[Eric Rescorla]

On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara 
wrote:

> On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> >
> > 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> > are jointly used to produce the traffic keys and also to form a MAC over
> > the handshake. As Hugo pointed out originally, this alone should
> > be sufficient to authenticate the server's side of the connection and
> > you could omit the server CertificateVerify (Hugo, please correct
> > me if I have misunderstood).
>
> Is it guaranteed that the groups are the same?
>

Yes, it's a requirement that the groups be the same. If the text doesn't
say that, it should.



> Even if it is, due to implementation bugs, bad idea to rely upon that.


Can you expand on this point? Is there a specific easy-to-make
implementation
error you are concerned with?



>
> > Trying to read between the lines, is your concern that the server is
> > now no longer explicitly signing over the ServerConfiguration in
> > its CertificateVerify [Note that the client continues to do so]? The idea
> > behind removing that was to make the 1-RTT part of the handshake
> > more uniform regardless of whether 0-RTT data was used.
> > I'm certainly open to putting that back in if it's needed, but can you
> > explain your concern in more detail?
>
> The concern is that attacker that has managed to inject g^s for
> known s is able to impersonate the server even through server certificate
> validation on subsequent connections (under some conditions).
>

I'm sorry, I'm still not following. All the data that the server sends is
tied to
g^y which is signed with the server's certificate, so even if s were
published,
the attacker should not be able to inject data which the client would
accept.

With that said, it's certainly true that if the attacker is able to
convince the
client that the server has a certain g^a where a is known to the attacker,
then the client has a problem because he will encrypt data *to* the
attacker in 0-RTT, so obviously we are assuming that the attacker does
not know s and cannot convince the client to accept a g^s of his
choice.


(Indirectly) signing g^s would prevent this.
>
> ... Funkily enough, this attack doesn't work against either tls-unique
> nor tls-extractor (however, those still fail nonce check with respect
> to SS)...


Do you think you could draw a ladder diagram that shows the attack you
are concerned about?

-Ekr






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

Re: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting record headers: practical for TLS 1.3 after all?)

[Eric Rescorla]

On Wed, Dec 2, 2015 at 7:34 AM, Jacob Appelbaum  wrote:

> On 12/2/15, Eric Rescorla  wrote:
> > On Wed, Dec 2, 2015 at 1:07 AM, Bryan Ford 
> wrote:
> >
> >> On 02 Dec 2015, at 06:02, Martin Thomson 
> >> wrote:
> >> > On 1 December 2015 at 08:22, Bryan A Ford 
> >> > wrote:
> >> >> 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.
> >> >
> >> > 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).
> >>
> >> 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.
> >
>
> I think that it eliminates all static distinguisher in the protocol
> for all data covered by the encryption. That is a fantastically
> wonderful benefit.


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.


> -Ekr
> >
> > [0] This issue doesn't apply to DTLS because the stack will just move
> onto
> > the next UDP datagram.
>
> 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?


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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jacob Appelbaum]

On 12/2/15, Martin Rex  wrote:
> Jacob Appelbaum wrote:
>>
>> 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.
>
> Hiding SNI data is completely silly security-wise, and any TLSv1.2
> 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.

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

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

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

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

[Salz, Rich]

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

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

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

[Eric Rescorla]

On Wed, Dec 2, 2015 at 10:00 AM, Salz, Rich  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
> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jacob Appelbaum]

On 12/2/15, Salz, Rich  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
>> 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.)
>

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
> Yokohama, but not very well. :)  They're presumably working on something
> better.
>

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

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

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

[Salz, Rich]

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

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

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

[Martin Rex]

Jacob Appelbaum wrote:
> On 12/2/15, Martin Rex  wrote:
>>
>> 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.
> 
> 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.

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


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

That is a myth.

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

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


-Martin

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

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

[Ilari Liusvaara]

On Wed, Dec 02, 2015 at 05:53:40PM +, Jacob Appelbaum 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 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

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

Re: [TLS] Draft status and updates

[Ilari Liusvaara]

On Wed, Dec 02, 2015 at 09:29:23AM -0800, Eric Rescorla wrote:
> On Wed, Dec 2, 2015 at 9:08 AM, Ilari Liusvaara 
> wrote:
> 
> > On Tue, Dec 01, 2015 at 11:19:15AM -0800, Eric Rescorla wrote:
> > >
> > > 3. The server provides g^y in his ServerHello and then g^xy and g^xs
> > > are jointly used to produce the traffic keys and also to form a MAC over
> > > the handshake. As Hugo pointed out originally, this alone should
> > > be sufficient to authenticate the server's side of the connection and
> > > you could omit the server CertificateVerify (Hugo, please correct
> > > me if I have misunderstood).
> >
> > Is it guaranteed that the groups are the same?
> 
> Yes, it's a requirement that the groups be the same. If the text doesn't
> say that, it should.

If the document says that, it is so unclear that I didn't even find the
requirement.
 
> > Even if it is, due to implementation bugs, bad idea to rely upon that.
> 
> Can you expand on this point? Is there a specific easy-to-make
> implementation error you are concerned with?

There is long history of TLS implementations omitting all kinds of checks,
even ones explicitly called as MUST.

E.g. It would surprise me more not to see any TLS 1.3 implementations that
decrypt 0-RTT data with ciphersuite different from negotiated (despite the
spec clearly forbidding this) than seeing those.
 
> > > Trying to read between the lines, is your concern that the server is
> > > now no longer explicitly signing over the ServerConfiguration in
> > > its CertificateVerify [Note that the client continues to do so]? The idea
> > > behind removing that was to make the 1-RTT part of the handshake
> > > more uniform regardless of whether 0-RTT data was used.
> > > I'm certainly open to putting that back in if it's needed, but can you
> > > explain your concern in more detail?
> >
> > The concern is that attacker that has managed to inject g^s for
> > known s is able to impersonate the server even through server certificate
> > validation on subsequent connections (under some conditions).
> >
> 
> I'm sorry, I'm still not following. All the data that the server sends is
> tied to
> g^y which is signed with the server's certificate, so even if s were
> published,
> the attacker should not be able to inject data which the client would
> accept.

I would certainly expect the signature check, if it is there at all, to
be proper nonce over SS.

IIRC, the key exchange is explicitly intended to be secure (but forward
security is lost) if ES is revealed.

Config-authenticated ciphersuites are different matter (the main
challenge there seems to be deciding when those are to be enabled[1],
not so much designing the key exchange[2]).

> With that said, it's certainly true that if the attacker is able to
> convince the
> client that the server has a certain g^a where a is known to the attacker,
> then the client has a problem because he will encrypt data *to* the
> attacker in 0-RTT, so obviously we are assuming that the attacker does
> not know s and cannot convince the client to accept a g^s of his
> choice.

Oh yeah, that too... I don't work with 0-RTT that much, as it is way
harder to analyze than 1-RTT (bad thing, I know).



[1] Persistent inpersonation and all that...

[2] Require server to send EarlyData if one is used, then just omit
server Certificate and CertificateVerify.


-Ilari

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

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

[Fabrice Gautier]

> On Dec 2, 2015, at 01:51, Bryan Ford  wrote:
> 
>> On 02 Dec 2015, at 00:54, Fabrice Gautier  wrote:
>>> On Tue, Dec 1, 2015 at 7:27 AM, Bryan A Ford  wrote:
 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. […]
>> 
>> Hum I wouldn't qualify this as a "fairly simple" solution.
> 
> A reasonable but subjective position, which I think we should further discuss 
> later if/when this (or some) WG actually revisits DTLS. :)

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. 

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

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

[Dave Garrett]

On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
> 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.)

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

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

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

[Peter Gutmann]

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

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

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

[Jacob Appelbaum]

On 12/2/15, Salz, Rich  wrote:
>> 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.

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.

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

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

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

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

[Jacob Appelbaum]

On 12/2/15, Martin Rex  wrote:
> Jacob Appelbaum wrote:
>> On 12/2/15, Martin Rex  wrote:
>>>
>>> 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.
>>
>> 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.
>
> No you can NOT do this (in TLSv1.2 and earlier), because it is entirely
> backwards-incompatible.

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.

>
> Server-side SNI can even be implemented completely outside of the 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
>> secure
>
> That is a myth.

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

>>
>> 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.
>
> TLSv1.3 is looking more and more like a future market failure to me,
> worse than IPv6.

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

All the best,
Jacob

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

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

[Salz, Rich]

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


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

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

[Eric Mill]

On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum  wrote:

> On 12/2/15, Salz, Rich  wrote:
> >> 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.
>
> 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.
>

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
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Jacob Appelbaum]

On 12/2/15, Dave Garrett  wrote:
> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>> 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.)
>
> URL from Rich's previous email citing this:
> 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

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

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

[Martin Thomson]

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.

On 3 December 2015 at 14:38, Jacob Appelbaum  wrote:
> On 12/2/15, Dave Garrett  wrote:
>> On Wednesday, December 02, 2015 01:00:26 pm Salz, Rich wrote:
>>> 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.)
>>
>> URL from Rich's previous email citing this:
>> 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

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

[Jacob Appelbaum]

On 12/3/15, Salz, Rich  wrote:
>> 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.
>

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

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

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

[Jacob Appelbaum]

On 12/3/15, Eric Mill  wrote:
> On Wed, Dec 2, 2015 at 7:52 PM, Jacob Appelbaum 
> wrote:
>
>> On 12/2/15, Salz, Rich  wrote:
>> >> 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.
>>
>> 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.
>>
>
> 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.

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.

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

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.

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

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

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

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

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

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

[Jacob Appelbaum]

On 12/3/15, Martin Thomson  wrote:
> There are a lot of inaccuracies in that presentation, so I wouldn't
> pin too much on it.
>

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!

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

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.

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

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

All the best,
Jacob

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

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

[Viktor Dukhovni]

On Thu, Dec 03, 2015 at 03:49:02AM +, Jacob Appelbaum 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.

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.

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