Subject: TLS 1.1/1.2 impact on applications protocols - msg#00040

Previous Message by Date: click to view message preview

Re: New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt

--On Monday, 29 January, 2007 22:32 +0100 Bjoern Hoehrmann <derhoermi@xxxxxxx> wrote: >... >> * The issue of escaping escapes has been avoided, >> leaving that problem to the applications and protocols >> that use the escapes. That may not be good enough, but >> it at least moves us forward and should facilitate a >> focused discussion. > > I think better discussion of this case, and also escaping > characters with some pre-defined meaning inside a protocol > element that accepts UTF-8, is necessary. E.g., in section 1.1 > it is said "This recommen- dation is not applicable to > protocols that already accept native UTF-8 or some other > encoding of Unicode." I am not sure how to read that in such a > case. If the protocol can actually accept UTF-8 (or UTF-16 or UTF-32), this recommendation is not applicable at all. If it is somehow necessary to escape Unicode characters that have special interpretations in those environments, that is the problem of the relevant protocols. Beyond that, I'm always open to suggested text. > Some nits: > > In section 3 I am not sure how to read "U+NNN[N[N]]". Perhaps > there is an "N" missing? That is correct. And <obscenity>, I thought I had caught all of those. Fixed in -02. Sorry. > I think this should say instead in > prose that four to six digits should be used. Section 1.1 uses > "U+NNNN[N[N]]", there I'd prefer to simply use U+NNNN or > U+NNNNNN. But, as long as five characters is permissible (and it is a frequent case), either of those two cases would be wrong. I've added prose in the working draft for -02 to the first case. > In section 5.2 it is said HTML uses the &#xNNNN; form and that > this form has a clear terminator. This is not really false but > HTML allows to omit the terminator if it is not needed, for > example <p>Bj&#xf6rn</p> is also valid. I would suggest to > mention only XML or note that HTML's mechanism is similar to > that of XML. Good. Will fix. thanks, john

Next Message by Date: click to view message preview

RE: TLS 1.1/1.2 impact on applications protocols

> -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@xxxxxxx] > Sent: Monday, January 29, 2007 11:38 PM > To: Apps Discuss > Cc: Pasi Eronen; Eric Rescorla > Subject: TLS 1.1/1.2 impact on applications protocols > > The changes that are happening in the TLS WG with the > publication of TLS 1.1 and the upcoming TLS 1.2 do have a > significant impact on application deployment. Many of our > application protocols make TLS 1.0 mandatory-to-implement. > I'd like to see a discussion of the importance of transition > to 1.2 (when it comes out) and the real-world problems that > might occur. Do we need to update our application protocol > specifications to mandate the newer version? Or perhaps we > need an app-area RFC which does that to a set of application > protocols? > > Can we just have a blanket exception to the standards status > (proposed/draft/full) reference rules for the TLS base spec > (and trust the TLS WG to do the right thing)? It seems more > important to keep up-to-date on security technology than to > have normative reference purity. > > Perhaps this would be a good topic for the Prague apparea meeting? I just ran into this very situation in the process of bringing EPP (RFCs 3730 - 3734) to Draft. The IESG was OK with a normative downward reference to TLS 1.0 and some additional text to note that the work is still evolving. Here's what we agreed to say: "When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication." The reference to 2246 is normative; a downref note and exception processing was required. The reference to 4346 is informative. This approach worked because EPP does not depend on any version-specific features of TLS. The situation may well be different for other protocols. -Scott- <<attachment: winmail.dat>>

Previous Message by Thread: click to view message preview

New draft (Was: I-D ACTION:draft-klensin-unicode-escapes-00.txt

Hi. We have reached the point at which several people are repeating essentially the same suggestions. That probably represents progress, but it also indicates to me that the -00 version of the draft has outlived its usefulness. I've just submitted draft-klensin-unicode-escapes-01.txt and assume it will show up in the posting directory today or tomorrow. Highlights (if I got things right): * All of the typographic editorial errors that have been identified have been fixed. * The preference for \u / \U has been removed and the document restructured to express no preference among the several ways to denote Unicode code points. However, the preference of many for paired delimiters has been made explicit, as has a prohibition on surrogates. * The issue of escaping escapes has been avoided, leaving that problem to the applications and protocols that use the escapes. That may not be good enough, but it at least moves us forward and should facilitate a focused discussion. There are two sets of suggestions I haven't followed (yet): * Frank made a strong recommendation that we make an explicit and normative reference to W3C's CharMod spec and call out several of its explicit rules. There is a tradeoff with length, additional need to read other documents, and general document and reading complexity. It may no longer be needed. Opinions and comments welcome. * I have not touched the ABNF associated with the \u / \U case. I have inserted an explicit placeholder but, as discussed on this list, I think we need to figure out what we want to do and then go back and adjust the metalanguage productions. In particular, there has been one strong suggestion, with which I agree, that we not take the obvious approach of substituting %x5C.75 for "\u", since the intent is a character string abstraction (independent of the implementation character set) rather than specific octets. thanks, john

Next Message by Thread: click to view message preview

RE: TLS 1.1/1.2 impact on applications protocols

> -----Original Message----- > From: Chris Newman [mailto:Chris.Newman@xxxxxxx] > Sent: Monday, January 29, 2007 11:38 PM > To: Apps Discuss > Cc: Pasi Eronen; Eric Rescorla > Subject: TLS 1.1/1.2 impact on applications protocols > > The changes that are happening in the TLS WG with the > publication of TLS 1.1 and the upcoming TLS 1.2 do have a > significant impact on application deployment. Many of our > application protocols make TLS 1.0 mandatory-to-implement. > I'd like to see a discussion of the importance of transition > to 1.2 (when it comes out) and the real-world problems that > might occur. Do we need to update our application protocol > specifications to mandate the newer version? Or perhaps we > need an app-area RFC which does that to a set of application > protocols? > > Can we just have a blanket exception to the standards status > (proposed/draft/full) reference rules for the TLS base spec > (and trust the TLS WG to do the right thing)? It seems more > important to keep up-to-date on security technology than to > have normative reference purity. > > Perhaps this would be a good topic for the Prague apparea meeting? I just ran into this very situation in the process of bringing EPP (RFCs 3730 - 3734) to Draft. The IESG was OK with a normative downward reference to TLS 1.0 and some additional text to note that the work is still evolving. Here's what we agreed to say: "When layered over TCP, the Transport Layer Security (TLS) Protocol version 1.0 [RFC2246] or its successors (such as TLS 1.1 [RFC4346]), using the latest version supported by both parties, MUST be used to provide integrity, confidentiality, and mutual strong client-server authentication." The reference to 2246 is normative; a downref note and exception processing was required. The reference to 4346 is informative. This approach worked because EPP does not depend on any version-specific features of TLS. The situation may well be different for other protocols. -Scott- <<attachment: winmail.dat>>