Subject: [TLS] Short notes on TLS RFCs ...

From: Colm MacCárthaigh <[email-masked]>
Date: Thu, 19 Jun 2014 20:32:45 -0700

I've recently spent some time reading various TLS RFCs in detail.
During the process I found a few points of confusion, or inconsistency
with what I could find in general implementations. As I'm new to this,
I may be duplicating reports, and I may also be in error. Apologies if
so, but it seemed worth sending a note all the same.

1. I don't think RFC5246 actually specifies how DH parameters should
be signed. In section 7.4.3 signed_params is defined as "a signature
over the server's key exchange parameters" and appendix F (which is
non-normative?) described that the parameters are hashed with the
hello.random values, but does not say how.

RFC4346 does contain a description; but it was not clear to me what
should be done in TLS1.2 without reverse engineering it from existing
implementations.

Again, my apologies if I've missed it - but I can't find a clear
instruction on how to sign the parameters in the RFC.

I think a future RFC could benefit from a small repair work here and
I'd be happy to contribute if that's appropriate.

2. The handling of alert messages is somewhat ambiguous. I think a
strict reading of the sections on the record layer imply that alert
messages may be fragmented across more than one record, and also that
several alerts (and also maybe a partial alert) may be coelesced into
a single record. Some experiments with implementations show me that
this is inconsistently handled.

Because alert messages specify the AlertLevel before the alert code,
there is a possibility for ambiguity with the intent of section 7.2.
Suppose that a peer send the first byte of an alert message, and that
that byte is "2". As the recipient, I know that I have a fatal alert.
Should I shut the connection down immediately? Or is the alert message
considered incomplete until the entire message is received? If the
subsequent record, with the second byte of the alert message also
contains other alert messages - what status should I give those? where
a peer chooses to indicate several alerts in one record, should it be
clear that a fatal alert truncates the alert stream?

Is there a reason to support fragmentation/coalescing for alerts at all?

3. The purpose of heartbeat message seems to be a form of path MTU
discovery, but they also seem ill-suited to MTU discovery. In
particular, Heartbeat messages seem to me capable of only discovering
the lowest-MTU supported in both directions of transmission; rather
than the actual MTU of the network paths; which can be (and sometimes
are) asymmetrical.  This may seem very esoteric, but as WANs and
transit providers deploy jumbo-frames inconsistently, asymmetrical
MTUs are becoming more common. Though hopefully that day will pass.

Again, apologies if my notes are duplicative, but figured it was
better to report a dupe than to miss something.

-- 
Colm

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 20 Jun 2014 07:50:29 -0400

Thanks; it is always useful to have a fresh pair of eyes!

>  I think a future RFC could benefit from a small repair work here and I'd be happy to contribute if that's appropriate.

Yes, particularly if you have suggested wording.

> Is there a reason to support fragmentation/coalescing for alerts at all?

Not supporting it adds a special case, no?

Clarification around multiple alerts at once would be useful. But a fatal alert should be the last thing sent. Whether or not you read the whole message is a quality of implementation issue, I'd think.

Heartbeat is dead.

	/r$

--  
Principal Security Engineer
Akamai Technologies, Cambridge, MA
IM: [email-masked]; Twitter: RichSalz

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 20 Jun 2014 14:15:34 +0200

> MTUs are becoming more common. Though hopefully that day will pass.
No, heartbeat messages contain a payload being reflected and a padding
being discarded. Therefore you can send your (large) probe packet
containing a relatively small payload and a padding to get it to
the size you want to test, and just get back a small answer containing
the payload (and a small padding). So the padding is there especially
for dealing with asymmetric paths.

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

---

From: Watson Ladd <[email-masked]>
Date: Fri, 20 Jun 2014 09:31:45 -0300

> for dealing with asymmetric paths.

So Heartbleed is a feature: send a small packet and get a large
response for the direction you want to test.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 20 Jun 2014 15:07:06 +0200

> response for the direction you want to test.
No... You send a large packet (mostly containing padding) and get
back a small one (mostly containing the reflected payload)...

Best regards
Michael

---

From: Robert Ransom <[email-masked]>
Date: Fri, 20 Jun 2014 06:10:23 -0700

> back a small one (mostly containing the reflected payload)...

‘Heartbleed’ allowed a party to send a small packet and receive a large reply.

Robert Ransom

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 20 Jun 2014 08:01:36 -0700

> back a small one (mostly containing the reflected payload)...

aha, thanks for the correction, that makes more sense.

-- 
Colm

---

From: Colm MacCárthaigh <[email-masked]>
Date: Fri, 20 Jun 2014 08:53:02 -0700

> Yes, particularly if you have suggested wording.

Thanks for the encouragement, I have made the following suggested
change via a pull request;

https://github.com/tlswg/tls13-spec/pull/46

Hopefully it can be considered an editorial change and non-controversial.

-- 
Colm

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Jun 2014 09:42:58 -0700

The draft has been updated.

Thanks!

-Ekr

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 20 Jun 2014 21:29:59 -0700

> ‘Heartbleed’ allowed a party to send a small packet and receive a large reply.

The coding error in Open SSL allowed for that. The specification, on the other hand, specified that the reflected payload could not be larger than the incoming message. If the code had actually implemented the spec, there would be no bug.

-- Christian Huitema