Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 4 Jan 2005 18:58:06 +0200

On Thursday 30 December 2004 17:34, Simon Blake-Wilson wrote:
> Hi folks,
>
> We just posted an internet-draft updating the extensions RFC to deal with
> the issue of which documents can define new extensions - the current RFC
> allows only standards track RFCs while this draft allows any RFC based on
> IETF consensus (which basically means IESG review).
Since it is being updated I'd suggest to increase the number of valid values 
for MaxFragmentLength. I think values for up to 2^16 would be ok. 

-- 
Nikos Mavrogiannopoulos

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: EKR <[email-masked]>
Date: Mon, 03 Jan 2005 09:20:46 -0800

> for MaxFragmentLength. I think values for up to 2^16 would be ok. 

That seems like it might create an interop problem, no?

-Ekr

---

From: [email-masked]
Date: Mon, 3 Jan 2005 18:50:52 +0100 (MET)

Nikos Mavrogiannopoulos
> for MaxFragmentLength. I think values for up to 2^16 would be ok.

Larger than 2^14?...

OTOH, is it possible to more explain the following text?

paragraph 2.3
...
Nonetheless "server initiated" extensions may be provided in the
future within this framework by requiring the client to first send an
empty extension to indicate that it supports a particular extension."

Badra

---

From: [email-masked]
Date: Mon, 3 Jan 2005 18:33:31 +0100 (MET)

Nikos Mavrogiannopoulos

Larger than 2^14?...

Is it possible to more explain the following text?

paragraph 2.3
...

Badra

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 3 Jan 2005 16:40:35 -0500

I agree that this might create an interop problem ... And I don't think we
want to get into changes that break backwards compatibility here.

BTW ... Am I missing something ... Values up to 2^16 would mean that you
can now negotiate to allow longer packets rather than fragment to require
shorter packets, wouldn't it?

Best regards. Simon

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of EKR
> Sent: Monday, January 03, 2005 12:21 PM
> To: Nikos Mavrogiannopoulos
> Cc: [email-masked]
> Subject: Re: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt
>
>
> >> We just posted an internet-draft updating the extensions
> RFC to deal
> >> with the issue of which documents can define new extensions - the
> >> current RFC allows only standards track RFCs while this
> draft allows
> >> any RFC based on IETF consensus (which basically means
> IESG review).
> > Since it is being updated I'd suggest to increase the
> number of valid
> > values

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Mon, 3 Jan 2005 16:44:04 -0500

To my mind it means that new extensions cannot specify that the server
sends a particular extension type unless the client has included the same
extension type in the client hello. But new extensions can get round this
by having the client send an empty extension of that type, thereby
allowing the server to respond.

This text has not changed from RFC3546, but if you think it should be
clarified, please suggest some text!

Best regards. Simon

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, January 03, 2005 12:51 PM
> To: [email-masked]
> > values for MaxFragmentLength. I think values for up to 2^16 
> would be 
> > ok.
> 
> Larger than 2^14?...
> 
> Nonetheless "server initiated" extensions may be provided in 
> the future within this framework by requiring the client to 
> first send an empty extension to indicate that it supports a 
> particular extension."
> 
> Badra
> 
>

---

From: [email-masked]
Date: Tue, 4 Jan 2005 14:57:38 +0100 (MET)

Hi Simon,

It may be sufficient to add somewhere in the text that an empty extension
has no type and that, if the client receives one or more extensions and it
wants to negotiate them, it must re-send an extended client hello with the
selected extensions.

Best regards,
Badra

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Tue, 4 Jan 2005 12:21:54 -0500

Hi Badra,

I think your reading is still different from mine. Perhaps this means the
text could use clarification.

In my thinking, an empty extension is not "type-less". New extensions, say
of type x, that are essentially server driven would require clients to
include an extension of type x in the client hello with extension data
empty. The server can then include an extension of type x in the server
hello and put any relevant info about the extension in the extension data.
Of course, this limits the amount of "negotiation" that can occur between
the server and the client.

To clarify this, I'd propose the following rewording of the paragraph:

"Nonetheless "server initiated" extensions may be provided in the future
within this framework - such an extension, say of type x, would require
the client to first send an extension of type x in the (extended) client
hello with empty extension_data to indicate that it supports the extension
type."

Best regards. Simon

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 04, 2005 8:58 AM
> To: Simon Blake-Wilson
> Cc: [email-masked]
> Subject: RE: FW: [TLS] I-D ACTION:draft-ietf-tls-rfc3546bis-00.txt
>
>
> Hi Simon,
>
> It may be sufficient to add somewhere in the text that an
> empty extension has no type and that, if the client receives
> one or more extensions and it wants to negotiate them, it
> must re-send an extended client hello with the selected extensions.
>
> Best regards,
> Badra
>
> > sends a particular extension type unless the client has
> included the
> > same extension type in the client hello. But new extensions can get
> > round this by having the client send an empty extension of
> that type,
> > thereby allowing the server to respond.
> >

---

From: Richard Goble <[email-masked]>
Date: Tue, 04 Jan 2005 17:14:36 -0600

Simon,

This implies that client code would have to include all possible
server extensions before the TLS server could take advantage
of the extensions that increased its efficiency.  It is doubtful that
developers will be given the time to insert new extensions if
there is not a known need.  In Badra's example, where the client
would send another client hello w/ extensions the handshake ends
up looking a lot like a SGC style handshake, which has
implications on the hash of the handshake messages.  Or you
could create a new client response to the server initiated extensions
that would be sent as the first response to the server after the
server hello done is sent.  If the client can't / won't accept the server
extension it simply proceeds as normal.  The server would then
decide if it wanted to terminate the handshake.

Best Regards,
Richard Goble

Simon Blake-Wilson wrote:

>>>To my mind it means that new extensions cannot specify that
>>>      
>>>
>>the server
>>    
>>
>>>This text has not changed from RFC3546, but if you think it
>>>      
>>>
>>should be
>>    
>>
>>------------------------------------------------------------------------
>>

---

From: David Hopwood <[email-masked]>
Date: Thu, 06 Jan 2005 08:25:17 +0000

> wants to negotiate them, it must re-send an extended client hello with the

The assumption when the extensions spec was designed was that a client would
know in advance what extensions it could possibly support. So it should
never need to re-send a hello for that reason.

The text seems quite clear to me, but since I wrote that part originally I
may not be the best person to judge.

-- 
David Hopwood <[email-masked]>

---

From: [email-masked]
Date: Thu, 6 Jan 2005 13:05:58 +0100 (MET)

> may not be the best person to judge.

Beyond the text, I wanted to say that the client may "interrogate" the
server to know what are the extensions supported by the server, by sending
an empty and "magic" extension with no-type. Thus, the client should
re-send an Extended Client Hello with the selected extensions.

Badra

---

From: "Simon Blake-Wilson" <[email-masked]>
Date: Thu, 6 Jan 2005 11:00:10 -0500

Hi Badra,

I guess I'm struggling to see the benefit of that unless the number of
extensions grows by a couple of orders of magnitude.

Best regards. Simon

> Sent: Thursday, January 06, 2005 7:06 AM
> To: [email-masked]
> Cc: [email-masked]
> > The assumption when the extensions spec was designed was 
> that a client 
> > would know in advance what extensions it could possibly 
> support. So it 
> > should never need to re-send a hello for that reason.
> >
> > The text seems quite clear to me, but since I wrote that part 
> > originally I may not be the best person to judge.
> 
> Beyond the text, I wanted to say that the client may 
> "interrogate" the server to know what are the extensions 
> supported by the server, by sending an empty and "magic" 
> extension with no-type. Thus, the client should re-send an 
> Extended Client Hello with the selected extensions.
> 
> Badra
> 
>

---

From: David Hopwood <[email-masked]>
Date: Thu, 06 Jan 2005 18:33:23 +0000

[email-masked] wrote:
>>The assumption when the extensions spec was designed was that a client
>>would know in advance what extensions it could possibly support. So it

This seems unnecessary, because the client can simply send its desired
parameters for each extension as if the server supported it. There are no
interactions between different extensions such that the client would need
to know whether the server supported one extension before deciding on the
parameters for another.

IIRC, this exact issue was considered by the authors and discussed on the
TLS list. A more complicated multi-round negotiation could have been
designed, but the current simple mechanism won out in the discussion.

If a client implementor disagrees with this reasoning and decides that
a multi-round negotiation is worth the additional complexity, then the
possibility of reconnecting and sending another hello is obvious, and
not prohibited by the current text.