On Fri, Sep 3, 2010 at 11:51 PM, RFC Errata System <[email protected]> wrote: > http://www.rfc-editor.org/errata_search.php?rfc=5216&eid=2510
> Section: 3.1 Please note that similar language exists in other places of the document, too (2.1.5 and 3.2) and the same comments should apply to them. > Original Text > ------------- > The L bit (length included) is set to indicate the presence of the > four-octet TLS Message Length field, and MUST be set for the first > fragment of a fragmented TLS message or set of messages. > > Corrected Text > -------------- > The L bit (length included) is set to indicate the presence of the > four-octet TLS Message Length field, and MUST be set for the first > fragment of a fragmented TLS message. The L bit MAY be included > in all fragments of a fragmented TLS message, but if included the > TLS Length MUST represent the entire length of the TLS message. This would still leave some potential uses of the L bit undefined. These two sentences cover only fragmented TLS messages. What about TLS messages that are not fragmented? It should also be noted that the proposed text would make RFC 5216 (EAP-TLS) inconsistent with RFC 5281 (EAP-TTLS) as far as fragmentation is concerned. I do not think that that would be a good idea since it is possible to share same implementation for handling fragmentation/reassembly of various TLS-based EAP methods (EAP-TLS, EAP-TTLS, EAP-PEAP, EAP-FAST). RFC 5281 disallows use of the L bit in the fragments other than the first one. In addition, it does actually cover the not fragmented message case, too: If there are multiple fragments, the first fragment MUST have the L bit set and include the length of the entire raw message prior to fragmentation. Fragments other than the first MUST NOT have the L bit set. Unfragmented messages MAY have the L bit set and include the length of the message (though this information is redundant). My preference would be for RFC 5216 to follow this design, but I don't think I would be willing to call this change "editorial".. Are there any known EAP-TLS implementations that actually use the L bit in fragments other than the first one? Would that interoperate with other EAP-TLS implementations? - Jouni _______________________________________________ Emu mailing list [email protected] https://www.ietf.org/mailman/listinfo/emu
