[TLS] Short notes on TLS RFCs ...

[Colm MacCárthaigh <[e-mail]>]

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