Henrick Hellström | 28 Nov 13:05 2015

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

On 2015-11-28 12:30, Kriss Andsten wrote:
> On 27 Nov 2015, at 17:21, Henrick Hellström <henrick <at> streamsec.se> wrote:
>> How, exactly, would this be significantly harder? The adversary will still be able to tell when, and how
much, TCP/IP data is sent between the peers. If there happens to be a revealing TLS record boundary in the
middle of a TCP/IP packet, it would seem to me there is an implementation problem rather than a problem with
the abstract protocol.
> This is actually quite common. Even when it does align with packet boundaries, it is providing known
information rather than inferred information ("here's a length X blob, then a length Y blob" vs "Here's a
bunch of packets whose lengths minus TLS headers amount to to X+Y").

Maybe I have missed something, but this seems awfully implementation 
dependent to me. Let's take a more specific example:

Suppose a web server is serving a request for a web page, which 
typically means that the client firstly sends a single HTTP request for 
the HTML page, and then multiple requests for the css, images, etc in a 

Most times, the latter row of requests could easily be encoded in a 
single TLS fragment. This means that the server will become aware of all 
of the requests at the same time, and might encode all of the HTTP 
responses before beginning to encode the TLS fragments.

Carefully implemented, such a solution would not necessarily require 
significantly more resources to handle pipe-lining, compared to an 
alternative solution that would serve, encode and send the responses 
on-the-fly, and as a consequence quickly fill up the outgoing TCP/IP queue.

(Continue reading)

Bryan A Ford | 27 Nov 15:35 2015

Encrypting record headers: practical for TLS 1.3 after all?

The idea of encrypting TLS record headers has come up before, the most
important purpose being to hide record lengths and boundaries and make
fingerprinting and traffic analysis harder.  I had convinced myself that
goal this would be "too hard" to accomplish in TLS 1.3, but after
further thought I'm not so sure.  So I would like to request comment on
one approach that strikes me as a practical and requires only a rather
minor change to the current spec.

The quick summary:

* To encrypt a record, we first AEAD-encrypt the record's payload,
protecting the header fields via the additional_data, exactly as
currently specified.  But then we XOR-encrypt the 5-byte TLS header just
before transmission, using a (separate) stream cipher indexed by a nonce
that depends on record sequence number and *_write_iv, in exactly the
same way the AEAD is already nonce-indexed.

* To decrypt a record, we simply do the reverse: first use the stream
cipher with the appropriate nonce to XOR-decrypt the 5-byte TLS header,
then sanity-check it as usual to determine its length, read the rest of
the record, and submit it to AEAD for decryption and full integrity
checking as before.

That's it, in a nutshell.  Two likely concerns immediately arise,
discussed below, but feel free to TL;DR the rest if you don't share
these concerns.


Concern #1: What if an active attacker messes with the TLS header,
(Continue reading)

Xuelei Fan | 27 Nov 12:58 2015

TLS 1.3 and RFC 4279, Pre-Shared Key Ciphersuites


In the draft spec of TLS 1.3, ServerKeyExchange and ClientKeyExchange get removed, and key_share extension applies to non-PSK cipher suites only. As RFC 4279 need ServerKeyExchange and ClientKeyExchange messages, I think TLS 1.3 updates or obsoletes RFC 4279.

Per the draft spec of TLS 1.3, if no suitable identity is provided in pre-shared key extension, the server MUST NOT negotiate a PSK cipher suite.  The question comes to me: where the suitable identity comes from?  The identity can be acquired by out-of-band approach, or the server NewSessionTicket message.  If no out-of-band approach in some circumstances, the server NewSessionTicket message would be the only way to create the identity.  The scenarios of using  pre-shared key may look like:
1. establish a fresh connection, server sends the NewSessionTicket to indicate it supports session resumption and provide the psk_identity.
2. if client wants a session resumption, subsequent handshaking will use pre_shared key extension with the server provided psk_identity.

Looks like PSK applies to session resume only in TLS 1.3, and cannot be used for fresh (initial) handshaking any more,  unless out-of-band approach is used to define the identities.  I have no experience on PSK, but looks like that it is not A minimal effort for PSK deployments to upgrade from TLS 1.2 to TLS 1.3, if ServerKeyExchange.psk_identity_hint is used previously.

It would be nice to consider and specify the impact on RFC 4279 in TLS 1.3 protocols.

TLS mailing list
TLS <at> ietf.org
Xuelei Fan | 27 Nov 03:38 2015

"selected_group" field in HelloRetryRequest in TLS 1.3


What's the consideration to place selected_group out of the extensions filed in HelloRetryRequest?

      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          NamedGroup selected_group;
          Extension extensions<0..2^16-1>;
      } HelloRetryRequest;


      struct {
          ProtocolVersion server_version;
          CipherSuite cipher_suite;
          Extension extensions<0..2^16-1>;   // use key_share (empty share) or
                                                              // supported_group for named groups
      } HelloRetryRequest;

The latter may be more friendly for future extensibility, and easier to implement.  For example, FFDHE may be easy to expose to pre-computation issues in the future, and dynamic safe prime groups may be expected at that time.  Having the selected_group as an extension might be more flexible  to define new replacement.

TLS mailing list
TLS <at> ietf.org
Dave Garrett | 27 Nov 00:03 2015

Replacing HelloRetryRequest in TLS 1.3?

HelloRetryRequest is annoying. Is there any way we can replace it with something? I know our options are
limited, here. We can't mandate offers for everything, not just due to constrained environments, but
also because post-quantum keys could get too big.

The main thing that comes to mind would be to provide a way for a server to respond to a client with a
ServerConfiguration, but not a hello, and put group support in there (maybe a whole supported_groups
extension). Clients that don't provide the needed key would get a config and a fatal alert telling it that
it needs to use a supported group from that config. The client could then retry as it does now or do 0-RTT with
early data, which could cut an RTT out of the current flow. (This is similar to the QUIC way of doing things.)

Xuelei Fan | 26 Nov 14:52 2015

Extensions "supported_groups" and "key_share" in TLS 1.3


Per the latest draft of TLS 1.3, both "supported_groups" and "key_share" extensions are REQUIRED for DHE or ECDHE cipher suites (Section 8.2).  Both extension need to provide the supported named groups in preference order.  Looks like the functions are overlapped.  I was wondering, it may be nice to obsolete the "supported_groups" extension, and use "key_share" extension for both the supported named groups and the key exchange information for each group.

For the "supported_groups" extension, the description is (Section
   Clients which offer one or more (EC)DHE cipher suites MUST send at
   least one supported NamedGroup value and servers MUST NOT negotiate
   any of these cipher suites unless a supported value was provided.  If
   this extension is not provided and no alternative cipher suite is
   available, the server MUST close the connection with a fatal
   "missing_extension" alert.  (see Section 8.2) If the extension is
   provided, but no compatible group is offered, the server MUST NOT
   negotiate a cipher suite of the relevant type.  For instance, if a
   client supplies only ECDHE groups, the server MUST NOT negotiate
   finite field Diffie-Hellman.  If no acceptable group can be selected
   across all cipher suites, then the server MUST generate a fatal
   "handshake_failure" alert.

For the "key_share" extension, the description is (Section
   Clients which offer one or more (EC)DHE cipher suites MUST send at
   least one supported KeyShare value and servers MUST NOT negotiate any
   of these cipher suites unless a supported value was provided.  If
   this extension is not provided in a ServerHello or retried
   ClientHello, and the peer is offering (EC)DHE cipher suites, then the
   endpoint MUST close the connection with a fatal "missing_extension"

The "supported_groups" extension defines the groups, while the "key_share" extension defines both the groups and the key exchange information.  Both extension has its own preferences for the supported named groups.  It's easy to get conflicted if the two preferences are not consistent.  The "key_share" extension contains the information of the supported named groups.  So, the information can be used to indicate the client supported named groups.  Maybe, for TLS 1.3, it is not necessary to use the "supported_groups" extension any more.

TLS mailing list
TLS <at> ietf.org
Bill Cox | 24 Nov 17:25 2015

Should we use proof-of-possession rather than signatures?

Much of the world seems to have switched to Schnorr-signature inspired ECC signature schemes such as ECDSA-P256 and Ed25519.  These schemes are very fast, but require two point multiplications to do a Schnorr-style verification.  A simpler proof-of-possession can be verified with only one point multiplication.

The server authentication scheme used in QUIC is for the server to prove possession of the static key when it encrypts the new ephemeral key share.  The trick is to take advantage of the key shares that have already been computed.  The client has already computed its ephemeral keyshare, and the server just uses its static keyshare from the server config.  The CertificateVerify message could be generated by the server computing the ECDHE shared secret between its static secret and the client's ephemeral keyshare, and then encrypt of the client random as it's proof.  The client verifies the proof by decrypting the nonce.  As with Schnorr signatures, creating the proof takes only one multiply: in this case the server multiplies the client's keyshare by it's static keyshare secret.  Instead of having to do two scalar point multiplications, the client only has to multiply the server's static keyshare by its ephemeral keyshare secret.  The proof is also smaller: 32 bytes vs 72 for ECDSA-P256.

This proof-of-possession is not a digital signature, since it can only be used to prove to the client that the server possesses the static private key.  However, I don't see any reason to create a full digital signature.  Is there any?  I just don't like seeing something as fast as QUIC degraded when we switch to TLS 1.3.  I guestimate this will cost every connection ~1/8th of a millisecond when using ECDSA-P256.  Running "openssl speed ecdsap256", I get:

Doing 256 bit sign ecdsa's for 10s: 90092 256 bit ECDSA signs in 9.99s 
Doing 256 bit verify ecdsa's for 10s: 37154 256 bit ECDSA verify in 9.99s

This is about 0.27ms per verification, and on most client machines, this will probably be slower.  I think we can nearly double this speed.

In TLS, microseconds count.  This seems like low hanging fruit to me.

TLS mailing list
TLS <at> ietf.org
Salz, Rich | 24 Nov 12:50 2015

Re: [acme] Fixed missing references (#48)



This is editorial and you should just merge it.


From: Dominic [mailto:notifications <at> github.com]
Sent: Tuesday, November 24, 2015 4:46 AM
To: ietf-wg-acme/acme
Subject: [acme] Fixed missing references (#48)


I was unable to generate the latest draft using make. This PR fixes the missing references.

You can view, comment on, or merge this pull request online at:


Commit Summary

  • Fixed missing references

File Changes

Patch Links:

Reply to this email directly or view it on GitHub.

TLS mailing list
TLS <at> ietf.org
Dave Kern | 23 Nov 21:17 2015

Re: Early code point assignments for 25519/448 curves

I support early code point assignment of these curves. 


Martin Thomson | 23 Nov 19:28 2015

Issue #348: 32bit timestamp in ServerConfiguration

>From the issue:

As far as I can see, the only timestamp used is expiration_date in the
ServerConfiguration (apart from X.509 validity checks which require
synchronised clocks). This is defined as seconds since UNIX epoch, and
will overflow sooner than later. Maybe either use a relative amount of
seconds here, or expand to a 64bit value!?

I suggest to use 32bit network byte order (same as
ticket_lifetime_hint), which value are the seconds how long this
configuration is valid, and thus may be cached for at most this amount
of seconds.

I don't want to see this change to a relative time.  That will mess
with our ability to create ServerConfiguration objects that live
outside of the handshake.

I have no real objection to expanding this to 64bit though.  (I'm
personally OK with stating that this is modulo 2^32, but recognize how
that might result in problems.)
Sean Turner | 23 Nov 15:21 2015

Early code point assignments for 25519/448 curves


We’ve received an early code point assignment for the following 4 (four) elliptic curve points that will
go in the "Supported Groups" Registry:

// ECDH functions.

// Signature curves.

These points will be included in the following 2 (two) drafts:

Early code points are permitted in the “Supported Groups” registry and the chairs (that’s us) need
to determine whether there is support for these assignments.  Some input has already been received and
those people do not need to respond again to this call, but we’d like to hear from others whether they
support early code point assignment for these curves.  If you do not please state why.  We’re looking for
input by November 30th.

TLS mailing list
TLS <at> ietf.org