Re: Gen-ART review of draft-ietf-tls-rfc4346-bis-09.txt

At Tue, 26 Feb 2008 12:53:42 +0200,
Miguel,

Thanks for your comments. I generally took these, but some
responses below.

Miguel Garcia wrote:
> Comments: The document is well written, as one could expect from a new
> iteration of an existing document. I have very minor comments and
> suggestions, mainly trying to get clarifications for a reader who hasn't 
> been in contact with TLS in the past. Take them at your own discretion.
> 
> - expand MD5, SHA-1, and PRF at its first occurrence (Section 1.2)

I think this makes sense for PRF, but not the others, which are
more names than acronyms at this point.

> - Following up the previous comment. May I suggest to add subsections in 
> the IANA considerations section, so that each registry gets a subsection 
> number? Essentially, each bullet point in Section 12 should be promoted 
> to its own subsection. Then the main text should refer to, e.g., 
> "Section 12.4" rather than the general Section 12. This will avoid 
> errors like the previous one.

I actually think this is too many sections, but I did clarify the
previous graf to make sure what registry was relevant.

> - Section 7.2.1 got me very confused:
> 
>    "Unless some other fatal alert has been transmitted, each party...."
> 
> The text implies a classification of alerts. At least, there are 'fatal 
> alerts' some presumably 'non-fatal'. Well, after some digging and 
> initial confusion, I found that Section 7.2 has one pseudo-code 
> classifying the alerts:
> 
>        enum { warning(1), fatal(2), (255) } AlertLevel;
>
> Since this is an important aspect for the protocol, I would suggest to 
> add one paragraph of text in Section 7.2 describing in human-readable 
> text the alert classification. The text should also describe the 
> implications of receiving a 'warning' alert versus a 'fatal' alert.

It's in the first graf of 7.2.

   One of the content types supported by the TLS Record layer is the
   alert type. Alert messages convey the severity of the message and a
   description of the alert. Alert messages with a level of fatal result
   in the immediate termination of the connection. In this case, other
   connections corresponding to the session may continue, but the
   session identifier MUST be invalidated, preventing the failed session
   from being used to establish new connections. Like other messages,
   alert messages are encrypted and compressed, as specified by the
   current connection state.

I added a little more clarifying text.

thanks,
-Ekr