References: <56586A2F.1070703@gmail.com>
 <FB2973EF-F16C-404A-980D-CA0042EC4AEB@gmail.com> <565DBC63.5090908@gmail.com>
To: "tls@ietf.org" <tls@ietf.org>
From: Bryan A Ford <brynosaurus@gmail.com>
Message-ID: <565DC935.2040607@gmail.com>
Date: Tue, 1 Dec 2015 17:22:13 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0)
 Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <565DBC63.5090908@gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="------------ms070405090005090706030703"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hF-eBKOpQof1YC_tY1roPT2jm5M>
Subject: [TLS] Fully encrypted and authenticated headers (was Re: Encrypting
 record headers: practical for TLS 1.3 after all?)
Precedence: list

This is a cryptographically signed message in MIME format.

--------------ms070405090005090706030703
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Some of the parallel discussion on the SSH list - especially comments by
Simon Tatham and Niels M=F6ller - 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.

=2E..where "X" is some reasonable value we discuss and decide on.

But my (new) proposal does not require all TLS implementations to
maintain a fixed record size.  If the sender implementation wants to use
variable-size records, it can still process batches of records written
together normally up until the last record in the batch.  But when
processing the last record in a write - or in general the last record
before "going idle" where it does not yet have a next record to send -
the sender simply "picks something."  That something might for example
be a minimum record size, meaning the next record will be big enough to
hold a "next record length" indicating a useful length, but will
otherwise be basically a no-op record, so we'll pay the cost of an extra
small record and AEAD encryption/decryption each time transmission
resumes after being idle.

Alternatively the sender of variable-length records might pick a
"typical record size" as the next-record-size to transmit in the last
record in a burst; that way once transmission resumes the next record
can probably carry useful data, but might need padding if its committed
size is larger than the amount of data to be transmitted.  The
(important) existence of the padding mechanism already added in TLS 1.3
makes this alternative possible.

DTLS:

Now there's still the important question of whether this (new) proposal
could be made to work in the context of DTLS.  For the DTLS case, my
current thinking is that some elements of my earlier proposal is
probably more suitable: namely using a stream cipher (or AEAD used as a
stream cipher) to encrypt and recognize the explicitly-transmitted
sequence numbers that DTLS needs.  This could operate basically the same
as I described in my earlier E-mail on this topic.  Note that the length
field is no longer a problem in DTLS as it is in TLS, because the
receiver already gets the length of the datagram from UDP.

Comments/discussion?  Is the above more (or less) palatable than my
previous proposal?

Cheers
Bryan



--------------ms070405090005090706030703
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CfgwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw
CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4
dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290
MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD
VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP
TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu
dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC
AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh
TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak
+FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC
ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr
vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC
ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC
4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd
BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud
HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs
Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz
ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj
mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb
4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ
26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT
9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl
tukWeh95FPZKEBom+nyK+5swggVBMIIEKaADAgECAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqG
SIb3DQEBCwUAMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy
MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE
AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h
aWwgQ0EwHhcNMTUwNjI0MDAwMDAwWhcNMTYwNjIzMjM1OTU5WjAmMSQwIgYJKoZIhvcNAQkB
FhVicnlub3NhdXJ1c0BnbWFpbC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDAPPVOZLVu2tZOao2osnGxGwYy7nC3UX8yoebrOfaNWkItIkUH6NQRKuqxuDE7127q48VH
c7kwmg4DifoOjxSjXyT+R9pR/ethFwjXiWCjsIaWbcFc6X7D1fIisO14z8D4luBO1LezNVB6
Dee8lMutP9OO4MmKWYq3+Jab9Rv/3BXCyiDDQfxhiuWFzZQTWpbzGGfwitcqPHH97PN4COCh
hhOuUS9Yt1qQBY8Gn36eVepKdz3YiF7ii/JDth1iA/zHK8pyim+OgERcwo6Ildqh59uy0IjM
AcKA1Mc34AgMQJdLlmhYAai5nMLOJQiFzfIyB6egjSyishx11rpL/xKlAgMBAAGjggHzMIIB
7zAfBgNVHSMEGDAWgBSSYWuC4aKgqk/sZ/HCo/e0gADB7DAdBgNVHQ4EFgQUpXGtiQ4RgWPr
1UjnydSPtyPTai8wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYI
KwYBBQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsG
DCsGAQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0
L0NQUzBdBgNVHR8EVjBUMFKgUKBOhkxodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9DT01PRE9T
SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3JsMIGQBggrBgEF
BQcBAQSBgzCBgDBYBggrBgEFBQcwAoZMaHR0cDovL2NydC5jb21vZG9jYS5jb20vQ09NT0RP
U0hBMjU2Q2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFpbENBLmNydDAkBggrBgEF
BQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMCAGA1UdEQQZMBeBFWJyeW5vc2F1cnVz
QGdtYWlsLmNvbTANBgkqhkiG9w0BAQsFAAOCAQEADDSBNRYWArRAPSTMC6DSrUOIWQ3J1CmE
XEYoQ4QByCkkybRUCgXIadTAUwj+D9ZX4HQxxvtOkb+uVQCnwbI6jGZj0Mpb7MWYOZDyeQT1
YEoUMRpeUUpTDd6iw3Em0Lf+rj7/VPlYKvErTCOnyEUm2z8MismcjPIFJ8Ud+HccyfpkhotJ
HbVBN+hSGm03l7YxVVzf9owzq7L5vCB5afJyTNt5x7qlLCcsiGBW2kSoQKaDAMwuYMp5YOgD
1doc/yWJSkiQAcKcWY2ALacs+a0FSItqT1rNk3tnHX2spIrBgDrv+5ybZXBBjAknetbTON5m
rWT2tzLgYpKPJLs49ETIoDGCBEEwggQ9AgEBMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UE
CBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01P
RE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRp
Y2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJYIZIAWUD
BAIBBQCgggJhMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1
MTIwMTE2MjIxM1owLwYJKoZIhvcNAQkEMSIEIFUp7roZ2OX8roddAsoGYnWUlfz8if+F9DYd
6pO275GzMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggq
hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZI
hvcNAwICASgwgcEGCSsGAQQBgjcQBDGBszCBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgT
EkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RP
IENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNh
dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMIHDBgsqhkiG9w0B
CRACCzGBs6CBsDCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl
cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV
BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt
YWlsIENBAhAWpZtNxHBkhVoG2HKaeabqMA0GCSqGSIb3DQEBAQUABIIBAAwcI1jMq2N26Cvg
vi5kaJ4uiFe1l/fKhWzNnzS+HeBmuF/LxtvyUTIWGdDOwiRTceSshOpVh1XK7pUAd7Kwq1Q5
v2Nc5E6SAgZ0TKzCtb5JMaQeuuUacaseJ98KJ3aZ91qeHMQWfbiBTwtASfDbydXA8ba5kp2i
rgfiFu/8CvWqjwMxVKXVuOZT/7234lTfBYPfJaqEUBzlRlqIBjdN1VVtp66g6TLBTgEfoMON
N96GD90abO/0LyYNeAI1yxyzcFMWXXN7e+Xtw4/UeNWCYh6lzkGYTvwuySx5oRMenDg5L3Gn
fiLf+YW8DiH5o9EfmrgKtvoxE3PaSK97rYPu9lwAAAAAAAA=
--------------ms070405090005090706030703--