|
|
Subject: TLS 1.1/1.2 impact on applications protocols - msg#00040
List: ietf.apps-discuss
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?
- Chris
Was this page helpful?
Thread at a glance:
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örn</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>>
|
|