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

[Michael Tuexen <[e-mail]>]

On 20 Jun 2014, at 05:32, Colm MacCárthaigh <[e-mail]> wrote:

> 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.
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
> 
> Again, apologies if my notes are duplicative, but figured it was
> better to report a dupe than to miss something.
> 
> -- 
> Colm
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>