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

[Yoav Nir]

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

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

Yoav

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

[Hubert Kario]

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

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

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

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

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

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

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

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

Re: [TLS] bikeshed: Forward Security or Secrecy?

[William Whyte]

If we want to change to “key erasure” we should synch with CFRG and SAAG to
ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so
broken that it needs fixing.



Cheers,



William



*From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Tony Arcieri
*Sent:* Monday, November 30, 2015 11:20 PM
*To:* Hugo Krawczyk
*Cc:* tls@ietf.org
*Subject:* Re: [TLS] bikeshed: Forward Security or Secrecy?



On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk 
wrote:

The more common term is "forward secrecy"



I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key
erasure"



-- 

Tony Arcieri
___
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?

[Aaron Zauner]

Hi,

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

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

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

Aaron



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] bikeshed: Forward Security or Secrecy?

[Eric Rescorla]

I am planning to use "forward secrecy"

On Tue, Dec 1, 2015 at 4:17 AM, William Whyte  wrote:

> If we want to change to “key erasure” we should synch with CFRG and SAAG
> to ensure it’s used IETF-wide. I don’t think that “forward secrecy” is so
> broken that it needs fixing.
>
>
>
> Cheers,
>
>
>
> William
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Tony Arcieri
> *Sent:* Monday, November 30, 2015 11:20 PM
> *To:* Hugo Krawczyk
> *Cc:* tls@ietf.org
> *Subject:* Re: [TLS] bikeshed: Forward Security or Secrecy?
>
>
>
> On Mon, Nov 30, 2015 at 8:09 PM, Hugo Krawczyk 
> wrote:
>
> The more common term is "forward secrecy"
>
>
>
> I'd second this. I'm also a fan of Dan Bernstein's recommended term: "key
> erasure"
>
>
>
> --
>
> Tony Arcieri
>
> ___
> 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?

[Yoav Nir]

On 1 Dec 2015, at 1:02 PM, Hubert Kario  wrote:

 If you think it is practical for the TLS 1.3 standard to specify a
 single, fixed record size that all implementations of TLS 1.3 must
 use (i.e., explicitly freeze not only the version field but the
 length field), then that would be great for traffic analysis
 protection and on that basis I would support that proposal.  But
 that frankly seems to me likely a bit too much to ask given the
 diversity of TLS implementations and use-cases.  Tell me if you
 believe otherwise.> 
>>> That will just round up to a multiple of 256 bytes the data sizes
>>> transmitted. Hardly an improvement over the current 16 byte blocks.
>> 
>> Closer to 512 bytes is better.
> 
> Either hardly helps if you're not transferring packets with null data to 
> really hide the amount of data transferred.

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

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

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

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

Yoav

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

[John Mattsson]

On 01/12/15 15:22, "TLS on behalf of Yoav Nir"  wrote:

>
>On 1 Dec 2015, at 1:02 PM, Hubert Kario  wrote:
>
> If you think it is practical for the TLS 1.3 standard to specify a
> single, fixed record size that all implementations of TLS 1.3 must
> use (i.e., explicitly freeze not only the version field but the
> length field), then that would be great for traffic analysis
> protection and on that basis I would support that proposal.  But
> that frankly seems to me likely a bit too much to ask given the
> diversity of TLS implementations and use-cases.  Tell me if you
> believe otherwise.>
 That will just round up to a multiple of 256 bytes the data sizes
 transmitted. Hardly an improvement over the current 16 byte blocks.
>>> 
>>> Closer to 512 bytes is better.
>> 
>> Either hardly helps if you're not transferring packets with null data
>>to 
>> really hide the amount of data transferred.
>
>I think this is not as black and white as you suggest.
>
>It is possible to totally hide the actual data stream by sending a
>constant-rate stream of constant-size data records regardless of the
>availability of actual data. This is a perfect counter-measure to traffic
>analysis but it has a huge cost in bandwidth. Endpoints who do that might
>well be considered to be DoS-ing the network.
>
>There are less drastic ways. You could add small variations to the timing
>and sizes of records, adding a little padding, splitting and combining
>the application writes, perhaps with the addition of the occasional burst
>of fake traffic. This can have a relatively small overhead and obscure
>the real sizes and number of requests. An attacker will still have an
>approximation of the amount of real traffic is actually passed, but would
>not be able to guess which Wikipedia article you are viewing or what part
>of the world you are looking at with your favorite maps website. This is
>not as perfect as the full traffic flow confidentiality above, but it
>would be more palatable to network administrators and to people who pay
>for Internet access by the megabyte.
>
>I don’t think this is the same as encryption where you either have
>perfect security or you have nothing at all. There can be incremental
>gains that are worth having at significantly lower cost than the perfect
>TFC.
>
>Yoav

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

John

___
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 A Ford]

On 12/1/15 10:12 AM, Yoav Nir wrote:
>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum  wrote:
>> On 12/1/15, Viktor Dukhovni  wrote:
>>>* 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.

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

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

> If enough middleboxes block TLS 1.3, the browsers will implement a downgrade 
> dance. If they do that, attackers will be able to exploit the downgrade 
> dance. I don’t think the net effect is better 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.

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

B



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 A Ford]

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

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

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

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

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

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

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

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

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

Cheers
Bryan



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

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

[Bryan A Ford]

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

Proposal:

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

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

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

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

Choosing next-record lengths:

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

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

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

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

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

DTLS:

Now there's still the important question of whether this (new) proposal
could be made to work in the context of DTLS.  For the DTLS case, my
current thinking is that some elements of my earlier proposal is
probably more suitable: namely using a stream cipher (or AEAD used as a
stream cipher) to encrypt and recognize the explicitly-

Re: [TLS] Dumb thoughts for hardware backed keys for AEAD

[Ilari Liusvaara]

On Mon, Nov 30, 2015 at 06:07:19PM -0800, Bill Cox wrote:
> I don't think even I agree with this idea, but I'll put it out there anyway.
> 
> We're seeing some new secure computing modes in ARM and Intel processors.
> Arm has TEE, and Intel has SGX.  Both modes basically run at the same speed
> as the CPU... in theory.
> 
> There are potential benefits to securing the read/write session keys in
> these modes.  For example, if malware is doing evil things over your
> connections, when you remove the malware or close your laptop, the
> encryption keys are out of reach, and the connections go dead.  Otherwise,
> malware might export the keys where they could be used to resume a session,
> for example, enabling an attacker to continue doing evil.  This is possible
> today over TLS 1.2, even when using Client Certificates.
> 
> However, there are overhead costs for moving data in/out of these execution
> zones, and overhead when switching back and forth.  Execution speed is a
> little slower in these modes for various reasons.  For maximum speed, I
> might want a separate HMAC/HKDF key besides the read/write keys.  That way,
> I keep just the HMAC/HKDF key in a secure execution zone, and only have to
> do one small operation with it per AEAD call per TLS record.
> 
> This is just a dumb efficiency hack.  I hate leaving either speed or
> security on the table if I can have both :)  However, complexity harms
> security, so even I don't really think this is a good idea.  Is there
> anyone who feels even more strongly about speed than me?

If you want absolute maximum speed without handling encryption in the
secure module, you would essentially need the secure module to MAC the
data second time (one can repurpose any AEAD ciphers as a MAC).

(Hmm... why does this remind me of "key escrow"?... :-) )

The reason for this is that even the fastest hash-based MAC that is even
remotely secure (Blake2b native MAC) loses in speed to both main TLS 1.3
AEADs (doing full authenticated encryption).

You can't shorten things either, because the MACs in main TLS 1.3
AEADs are not designed to offer any security against attacker knowing the
keys. And as said, schemes that allow shortening are relatively slow.


-Ilari

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

[TLS] Draft status and updates

[Eric Rescorla]

Hi folks,

I've merged a bunch of PRs into the editor's draft, including:

- https://github.com/tlswg/tls13-spec/pull/316
  The new structure for client auth and post-handshake client
  auth we discussed in Yokohama.

- https://github.com/tlswg/tls13-spec/pull/342
  Using the "normal" content types for 0-RTT data and close_notify
  to indicate the end of the 0-RTT application data.

- https://github.com/tlswg/tls13-spec/pull/352
- https://github.com/tlswg/tls13-spec/pull/317
  Use SHA-1 to control what we sign with.

- https://github.com/tlswg/tls13-spec/pull/284
  The anti-downgrade mechanism that Karthik proposed

- https://github.com/tlswg/tls13-spec/pull/345
  Updating the IANA considerations per the discussion in Yokohama.


This clears out the big pipeline stall from PR#316, but probably has
created some bustage. Expect a series of cleanup commits and some
other things that were head-of-line blocked this week and then
draft-11 in the next week or so. Please file PRs and/or github
issues for any issues you see.

In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
implements the rekey mechanism that we discussed in Yokohama.  There
was broad agreement to adopt something like this.  I would appreciate
it if a few people could give it a sanity check, but absent strong
objections, I intend to merge this PR on Friday.


We also need to discuss three more substantive technical issues:

- Encrypted SNI.
- Whether the 0-RTT handshake messages are hashed into the
  handshake hash.
- Statelessness for HelloRetryRequest, and in particular cookie
  lifetime.

I'll be starting threads on those over the next few days with
the aim of resolving them promptly.

-Ekr
___
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 10:11:17AM -0800, Eric Rescorla wrote:
> 
> This clears out the big pipeline stall from PR#316, but probably has
> created some bustage. Expect a series of cleanup commits and some
> other things that were head-of-line blocked this week and then
> draft-11 in the next week or so. Please file PRs and/or github
> issues for any issues you see.

Looks like the note about the PSK+ClientCert "attack" got lost
somewhere. While I don't think that is important as the underlying
issue is fixed, I think there might be a note about dangers of using
server certificates in any mode where transcript and configuration
do not jointly imply SS.

Actually, scanning the editor's copy, it looks VERY broken to me:
I don't see how server certificate verify (indirectly) signs on the old
configuration. Such signing is required for security, as otherwise
SS is not impiled by signature, breaking authentication.

Previously, the document was clear about this...
 
> In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
> implements the rekey mechanism that we discussed in Yokohama.  There
> was broad agreement to adopt something like this.  I would appreciate
> it if a few people could give it a sanity check, but absent strong
> objections, I intend to merge this PR on Friday.

The restrictions on when the rekey message can be sent: Do those
essentially boil down to "any time after sending Finished"?

Also, I think the requirement to immediately send the KeyUpdate
is problematic. I think it should be requirement to send it as
next record(s).

The two aren't the same: The first seemingly requires scheduling
extra flights, which can be problematic. The second can piggyback
on existing flights. 
 


-Ilari

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

Re: [TLS] Draft status and updates

[Eric Rescorla]

Ilari,

Thanks for your quick review.

On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara 
wrote:

> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
> >
> > This clears out the big pipeline stall from PR#316, but probably has
> > created some bustage. Expect a series of cleanup commits and some
> > other things that were head-of-line blocked this week and then
> > draft-11 in the next week or so. Please file PRs and/or github
> > issues for any issues you see.
>
> Looks like the note about the PSK+ClientCert "attack" got lost
> somewhere.


See the last graf of:
http://tlswg.github.io/tls13-spec/#certificate-verify

I pointed to the e-mail by Sam's group and also prohibit entirely
the use of cert-based client auth in pure PSK, since that
seemed safer. If you think more is needed here I would be happy
to add it.


While I don't think that is important as the underlying
> issue is fixed, I think there might be a note about dangers of using
> server certificates in any mode where transcript and configuration
> do not jointly imply SS.
>



> Actually, scanning the editor's copy, it looks VERY broken to me:
> I don't see how server certificate verify (indirectly) signs on the old
> configuration. Such signing is required for security, as otherwise
> SS is not impiled by signature, breaking authentication.
>
> Previously, the document was clear about this...
>

I'm sorry, but I'm not following the issue you are raising here. Perhaps
you could expand further? Here's my reasoning.

1. The server delivers the server configuration in handshake #0
and signs the entire transcript with the certificate verify. At this
point the client has assurance of the server's g^s.

2. In handshake #1, the client sends g^x and there is authentication
for g^xs and hence the client knows that any data it is sending to the
server in 0-RTT is actually going to the server.

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

4. However, for consistency reasons (per the discussion in Prague),
the server *also* signs the entire transcript. This authenticates
g^y (even though the MAC with g^xs already authenticated it)
and proves possession of the signing key.

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?



> In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
> > implements the rekey mechanism that we discussed in Yokohama.  There
> > was broad agreement to adopt something like this.  I would appreciate
> > it if a few people could give it a sanity check, but absent strong
> > objections, I intend to merge this PR on Friday.
>
> The restrictions on when the rekey message can be sent: Do those
> essentially boil down to "any time after sending Finished"?
>

Except not during 0-RTT.


Also, I think the requirement to immediately send the KeyUpdate
> is problematic. I think it should be requirement to send it as
> next record(s).


> The two aren't the same: The first seemingly requires scheduling
> extra flights, which can be problematic. The second can piggyback
> on existing flights.
>

Good suggestion. PR welcome.  :)

-Ekr


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

[TLS] Fresh results

[Watson Ladd]

https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.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.

Sincerely,
Watson

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

Re: [TLS] Draft status and updates

[Eric Rescorla]

On Tue, Dec 1, 2015 at 11:19 AM, Eric Rescorla  wrote:

> Ilari,
>
> Thanks for your quick review.
>
> On Tue, Dec 1, 2015 at 10:57 AM, Ilari Liusvaara  > wrote:
>
>> On Tue, Dec 01, 2015 at 10:11:17AM -0800, Eric Rescorla wrote:
>> >
>> > This clears out the big pipeline stall from PR#316, but probably has
>> > created some bustage. Expect a series of cleanup commits and some
>> > other things that were head-of-line blocked this week and then
>> > draft-11 in the next week or so. Please file PRs and/or github
>> > issues for any issues you see.
>>
>> Looks like the note about the PSK+ClientCert "attack" got lost
>> somewhere.
>
>
> See the last graf of:
> http://tlswg.github.io/tls13-spec/#certificate-verify
>
> I pointed to the e-mail by Sam's group and also prohibit entirely
> the use of cert-based client auth in pure PSK, since that
> seemed safer. If you think more is needed here I would be happy
> to add it.
>
>
> While I don't think that is important as the underlying
>> issue is fixed, I think there might be a note about dangers of using
>> server certificates in any mode where transcript and configuration
>> do not jointly imply SS.
>>
>
>
>
>> Actually, scanning the editor's copy, it looks VERY broken to me:
>> I don't see how server certificate verify (indirectly) signs on the old
>> configuration. Such signing is required for security, as otherwise
>> SS is not impiled by signature, breaking authentication.
>>
>> Previously, the document was clear about this...
>>
>
> I'm sorry, but I'm not following the issue you are raising here. Perhaps
> you could expand further? Here's my reasoning.
>
> 1. The server delivers the server configuration in handshake #0
> and signs the entire transcript with the certificate verify. At this
> point the client has assurance of the server's g^s.
>
> 2. In handshake #1, the client sends g^x and there is authentication
> for g^xs and hence the client knows that any data it is sending to the
> server in 0-RTT is actually going to the server.
>
> 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).
>
> 4. However, for consistency reasons (per the discussion in Prague),
> the server *also* signs the entire transcript. This authenticates
> g^y (even though the MAC with g^xs already authenticated it)
> and proves possession of the signing key.
>
> 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]?
>

And, I should note the server's certificate.

-Ekr


> 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?
>
>
>
> > In addition, PR#354 (https://github.com/tlswg/tls13-spec/pull/354)
>> > implements the rekey mechanism that we discussed in Yokohama.  There
>> > was broad agreement to adopt something like this.  I would appreciate
>> > it if a few people could give it a sanity check, but absent strong
>> > objections, I intend to merge this PR on Friday.
>>
>> The restrictions on when the rekey message can be sent: Do those
>> essentially boil down to "any time after sending Finished"?
>>
>
> Except not during 0-RTT.
>
>
> Also, I think the requirement to immediately send the KeyUpdate
>> is problematic. I think it should be requirement to send it as
>> next record(s).
>
>
>> The two aren't the same: The first seemingly requires scheduling
>> extra flights, which can be problematic. The second can piggyback
>> on existing flights.
>>
>
> Good suggestion. PR welcome.  :)
>
> -Ekr
>
>
>>
>>
>> -Ilari
>>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Fresh results

[Hanno Böck]

On Tue, 1 Dec 2015 14:28:49 -0500
Watson Ladd  wrote:

> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.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.

So as long as you make sure you implement all the proper
countermeasures against that you should be fine. (Granted: This is
tricky, as has been shown by previous results, even the OpenSSL
implementation was lacking proper countermeasures not that long ago,
but it's not impossible)

Deprecating the RSA keyexchange just became a bit harder with Google's
intent to deprecate DHE in Chrome and use RSA as the fallback if the
host doesn't do ECDHE.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpbTiNagGGw2.pgp
Description: OpenPGP digital 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?)

[Dmitry Belyavsky]

Dear Bryan,

On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford  wrote:

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?

-- 
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 A Ford]

Hi Dmitry,

On 12/1/15 9:49 PM, Dmitry Belyavsky wrote:
> Dear Bryan, 
> 
> On Tue, Dec 1, 2015 at 7:22 PM, Bryan A Ford  > wrote:
> 
> 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.

Bryan



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?

[Fabrice Gautier]

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.
>
> The main issue is that DTLS packets need to contain explicitly
> transmitted sequence numbers rather than implicit sequence numbers,
> because packets can be received out of the order and the receiver needs
> to know which sequence number (and hence which nonce) to use to try to
> decrypt and integrity-check.  But if we encrypt the full DTLS header
> including sequence number, how does the receiver decrypt it without
> knowing the correct nonce to use to decrypt it?  An apparent
> chicken-and-egg problem.
>
> Fortunately the solution is fairly simple: the receiver simply
> pre-computes and keeps in a small hash table the encrypted sequence
> numbers of all packets with sequence numbers between H-W and H+W, where
> H is the highest sequence number correctly received so far (the horizon)
> and W is the anti-replay window size as specified in 4.1.2.5 of RFC
> 4347, which typically should be 32 or 64 according to the RFC.  The
> receiver can precompute all these encryptions because in my proposal TLS
> headers are encrypted with a stream cipher (or the AEAD operating as a
> stream cipher), so it's just a matter of producing the correct
> cipherstream bytes and XORing them with the uint48 sequence number.
>
> Whenever the receiver gets a datagram, it looks up the encrypted
> sequence number in the hash table, drops it on the floor if it's not
> present, and if it's present the receiver gets the decrypted sequence
> number from the hash table and uses that in the AEAD decryption and
> integrity-check.  In the low-probability event of a hash-table collision
> (i.e., two uint48 sequence numbers encrypting to the same 48-bit
> ciphertext in a single 129-datagram window), the receiver can
> trial-decrypt with both (or all) sequence numbers in that colliding hash
> table entry.  Or the receiver can keep it even simpler and just drop all
> but one colliding entry, introducing a pretty low probability of
> introducing occasional "false packet drops."
>
> The hash table is pretty trivial to maintain efficiently as well: e.g.,
> whenever the horizon H moves forward by delta D, remove the first D
> entries from the current window and precompute another D encrypted
> sequence numbers (where D will most often be 1).  In the simple design
> that doesn't bother dealing with hash table collisions (e.g., that
> allows each hash table entry to contain only one value), perhaps don't
> even bother clearing/removing old entries; just gradually overwrite them
> with new ones as H moves forward.

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

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


> But in the version of my proposal
> that operates the "normal" AEAD as a stream cipher for header
> encryption/decryption purposes, it doesn't seem like any change would be
> needed to the standard AEAD encryption/decryption interface.  It should
> even be fine if the AEAD was implemented as a separate hardware module
> that takes the standard AEAD interface inputs and produces the standard
> AEAD outputs; as long as it supports the standard AEAD API it should be
> perfectly usable in the design I proposed.
>
> The one potential issue I can think of if a particular, restricted API
> forces the caller to commit at key-setup time to either "AEAD encryption
> mode" or "AEAD decryption mode", and makes it difficult or impossible to
> switch back and forth.  In that case in my proposal as it stands the
> receiver TLS implementation might need to set up and maintain two
> hardware contexts, one for AE

Re: [TLS] Fresh results

[Dave Garrett]

On Tuesday, December 01, 2015 02:28:49 pm Watson Ladd wrote:
> https://www.nds.rub.de/media/nds/veroeffentlichungen/2015/08/21/Tls13QuicAttacks.pdf

This analysis was done against TLS 1.3 draft 07 from July. It changed to 
RSA-PSS signatures for handshake messages in draft 09. (current is draft 11; 
draft 12 is pending) This doesn't seem to change anything, though. QUIC also 
uses PSS.

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

I think it's reasonable at this point to publish a diediedie RFC for plain RSA 
use in all TLS versions and mandate expectation of (EC)DHE with RSA (or any 
certificate) everywhere. This technically wouldn't apply to IE6 on XP, as 
that's generally using SSL3, which already got its diediedie (MS left TLS 1.0 
off by default forever; anyone who can fix that can install something less than 
15 years old). IE7+ on Vista+ & Java 6+ support FS RSA cipher suites.

> Cross-protocol attacks are the gift that keeps giving.

Or, yet another lesson that just deprecating old features with new protocols is 
not enough. Keeping known-weak features around forever for backwards 
compatibility always seems to hurt you eventually.


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]

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

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

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

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

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

Peter.
___
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?)

[Martin Thomson]

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

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

[Viktor Dukhovni]

On Tue, Dec 01, 2015 at 09:02:34PM -0800, Martin Thomson wrote:

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

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

-- 
Viktor.

___
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 1 Dec 2015, at 4:55 PM, Bryan A Ford  wrote:
> 
> On 12/1/15 10:12 AM, Yoav Nir wrote:
>>> On 1 Dec 2015, at 3:36 AM, Jacob Appelbaum  wrote:
>>> On 12/1/15, Viktor Dukhovni  wrote:
   * 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.
> 
> Certainly there are middleboxes that try to use traffic analysis to
> detect attempts at tunneling - but the fact that the traffic is HTTPS
> doesn't mean there's no tunneling; in fact the HTTPS CONNECT operation
> does exactly that (and is sometimes used for exactly that purpose).
> 
> Regardless, does the IETF really want to be in the business of making
> sure that protocols like TLS are designed to avoid making life
> inconvenient for developers of Great Firewalls of whatever type?

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

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

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

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

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

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

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

Yoav


___
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 3:24 AM, Peter Gutmann  wrote:
> 
> 
> 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).
> 

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

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

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

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

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

Yoav


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