On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
On Jun 5, 2019, at 5:37 PM, Xuelei Fan <xuelei....@oracle.com> 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.
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.
That is true, but i believe it is extremely unlikely that the length would not
be in the ST empty extension, but the length would be in the ST resumption
extension.
I did not get the point.
If I read the appendix A of RFC 5077 correctly, the initial handshake
uses (for known implementation, which is the ambiguous part of RFC 4507):
00 23 Extension type 35
00 00 Length of extension contents
And session resumption uses (which is not ambiguous for RFC 4507):
00 23 Ticket Extension type 35
01 02 Length of extension contents
01 00 Length of ticket
FF FF .. .. Actual ticket
So it is the known format/behavior if RFC 5077 is right.
Xuelei
We have the system properties if an interop problem occurs. I’d rather see if we
encounter this problem in the 13 supported timeframe than construct a workaround
for potentially badly implemented resumption limited to TLS 1.0 & 1.1. Any
interop problem should result in a full handshake.
Tony
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
