On 6/5/2019 11:04 PM, Jamil Nimeh wrote:
Hi Xuelei, thanks for the feedback. A couple comments in-line below.
On 6/5/2019 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in
4507 (where there is both the extension_data length bytes AND the
opaque vector length) is not how deployed implementations did it. It
implies that deployed implementations do what you laid out below
where you just have 2 bytes of ID and 2 bytes of length. And I
believe that is compatible with what 5077 specifies.
Hm, I agreed with you.
So the potential problem is if one endpoint or the other happens to
implement 4507 to the letter, extra length bytes and all. But the
authors of 5077 say that no known implementations do this. That's
good for us I think, because in the two-ish years between 4507 and
5077 nobody did straight 4507, or they maybe did and fixed it by the
time 5077 came around.
I may view it differently.
If an implementation encoded per the format:
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticket
Just as your analysis previous, a RFC 5077 server will just ignore the
extension. No real hurt actually.
But if an implementation encoded empty SessionTicket extension per the
format (the known implementation):
00 23 Extension type 35
00 00 Length of extension contents
The server could read it as RFC 5077, and use stateless
implementation. When the ServerHello extension sent back. No matter
the RFC 4057 client accept it or not, there are interop issues.
If the client does not accept it (unlikely), the connection cannot be
established.
JN: Not necessarily. If the client doesn't accept it that doesn't mean
that it has to be fatal to the handshake.
We may be not talking about the same scenarios. Let me try again.
1. a RFC 4507 client send an empty ST extension for initial handshaking
in the format:
00 23 Extension type 35
00 00 Length of extension contents
2. a REFC 5077 server response with an en empty ST extension in ServerHello.
00 23 Extension type 35
00 00 Length of extension contents
3. if the RFC 4507 client cannot accept the ST in ServerHello, instead
of ignore the extension, the client will reject with a fatal alert and
then close the connection. Even if the client choose to ignore the ST
in ServerHello, I'm not sure if it could handle the coming
NewSessionTicket handshake message.
However, #3 is unlikely to happen because the client is already use this
format for the ClientHello message for empty SH message. I think
appendix A in RFC 5077 describe that the known RFC 4507 implementation
works. If #3 does not happen, it means the client accept the DH
message, and can establish the connection.
So we can rewrite 3 as 3':
3'. the RFC 4507 client accept the ST and NST, and the connection
established.
4. The RFC 4507 client uses the following format for session resumption:
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
5. The RFC 5077 server cannot parse the ST extension for the session
resumption, and the session resumption cannot be performed.
It just means resumption
cannot happen. I'd need to look at the spec to see what it says (if it
covers this edge case) but just thinking about it logically, a malformed
ticket shouldn't have to force an alert. It doesn't if we receive a
malformed ticket (Tony recently improved the logic around that ticket
processing to make sure of that), but it shouldn't mean the existing
handshake cannot otherwise complete.
If the client accept it, the resumption session will use the
negotiated ticket, and then non-empty SessionTicket extension is
encoded as:
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
The server would have to handle it (RFC 4507 format) if it want the
session resumption works. Here come the interop issues.
JN: Okay, I can see how this sequence of events could play out. That
said, I think before we contort ourselves into a pretzel to accommodate
this edge case, there should at least be some client out there that
people actually use (not some archived dust-bunny) that we can find that
behaves in this manner. Otherwise, my feeling is that we should just
support session tickets per 5077 and not any older obsoleted specification.
Sorry, I did not make me clear. I did not mean to support an obsoleted
specification. I meant that we could break the existing RFC 4507 based
applications.
Without this fix in server side, the existing RFC 4507 based client
application works as expected. It can establish the initial connection,
and can perform session resumption.
However, if the server upgrade with this patch, the existing RFC 4507
based client application cannot perform session resumption any more.
That's a compatibility impact to me.
Hope it is a little bit clear. Otherwise, let's have a meeting today.
Xuelei
Xuelei
I dug up a few pcaps I've kept around during testing of other TLS
features over the past few years. I had Chrome, Mozilla and OpenSSL
s_client pcaps and they all appear to follow the 5077 format. Of
course, anything after 2008 is more likely to do 5077 than 4507.
--Jamil
On 6/5/2019 4:35 PM, Xuelei Fan wrote:
I'm not sure I understand the following words in page 17, RFC 5077.
" An error in the encoding caused the specification to differ from
deployed implementations. At the time of this writing there are no
known implementations that follow the encoding specified in RFC
4507.
"
Is it means that the known implementation encode empty SessionTicket
extension as?
00 23 Extension type 35
00 00 Length of extension contents
Xuelei
On 6/5/2019 4:26 PM, Xuelei Fan wrote:
On 6/5/2019 3:37 PM, Jamil Nimeh wrote:
I think we're overstating the "otherwise" case. A client that
uses this strict 4507 format would initially send a ticket that
looks like { 00 23 00 02 00 00 } to which our server would reject
this extension (since the final 00 00 would be interpreted as a
ticket when the client did not intend it to be so). The result of
this SHOULD be that the server responds with a ServerHello that
doesn't have the SessionTicket extension.
That doesn't mean that resumption cannot happen. It just means
that resumption happens using the usual session ID lookup approach
and the server is caching the session rather than letting the
client do the work. Given that this is a degenerate case for what
(I hope) is a small subset of older clients, I think using
server-cached sessions is OK.
I don't believe we should ever find ourselves in a case where the
strict-4507 client actually gets a real ticket from our server,
and in turn should never hand us a ticket thinking that resumption
could actually take place via said ticket.
I'm not very sure if I read the Appendix A of RFC 5077 correctly. I
think it is trying to explain that client does not use strict-4507
for the empty extension and then result in the interop issues.
Page 18, RFC 5077:
" Note that the encoding of an empty SessionTicket extension was
ambiguous in RFC 4507. An RFC 4507 implementation may have
encoded
it as:
00 23 Extension type 35
00 02 Length of extension contents
00 00 Length of ticket
or it may have encoded it the same way as this update:
00 23 Extension type 35
00 00 Length of extension contents
"
On the client side, we cannot know ahead of time that the server
is strict-4057, so we have to send a 5077 style SessionTicket
extension. The server will probably not like that and not assert
SessionTicket in its server hello. So our client should fall back
to using the session ID to support resumption, and the server
should follow suit by caching the session.
I agreed. We should stick to the RFC 5077 format in client side.
Thanks,
Xuelei
--Jamil
On 6/5/2019 2:28 PM, Xuelei Fan wrote:
I don’t know if there are any deployment of RFC 4507. If not, we
are safe; otherwise there are interop problems for session
resumption.
Xuelei
On Jun 5, 2019, at 2:19 PM, Jamil Nimeh
<jamil.j.ni...@oracle.com> wrote:
Hi Xuelei,
Given that 4507 is obsoleted in favor of 5077 is there really
that much value to supporting this older/broken extension
format? Do we know of clients that still adhere to 4507?
Otherwise it seems better to stick to 5077 and the approach in
TLS 1.3 and not try to go back and support an earlier obsoleted
approach to this feature.
These lines took me to the cooperation behaviors between RFC
5077 and RFC 4507. It looks like we don't support RFC 4507
format of SessionTicket extension. As RFC 5077 and RFC 4507
use the same extension ID for different extension format. There
are potential compatibility issues, and make session resumption
impossible. I would like to have a workaround to accept both
formats. For example, using the a cookie at the beginning of
the ticket, as described in appendix-A of RFC 5077.
I will review the rest of this class in the afternoon or tomorrow.
Thanks,
Xuelei
