Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 20 Nov 2009 13:53:27 -0800

We have had a lot of good discussion on this list, but I think we need
to start converging on a solution. As I said in a previous message, I've
asked Eric to serve as editor for the WG draft and he has posted
draft-ietf-tls-renegotiation-00 as a starting point.  I realize that
there are a number of people who aren't happy with aspects of the draft,
or indeed with the draft as a whole, but I'd like to get the sense for
the feelings of the group as a whole. If we have rough consensus that
this is a workable approach, we can try to nail down the remaining
issues and move forward.

To try to keep this concrete, please respond with answers to this
question:

Support for the draft:
- I support this draft
- I support this draft with the following modification
- I would support an entirely different proposal (please identify it; be
specific) 

If you are proposing a modification, in addition to providing a
description and rationale for a modification to the document it is
helpful to provide sample text of the modification. Also, please
indicate whether you would only support the draft with your modification
or whether you can live with it unmodified.  

Thanks,

Joe

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 20 Nov 2009 16:03:17 -0600

> - I would support an entirely different proposal (please identify it; be

I support this draft with only INFORMATIVE modifications about the fact
that this is "like an RFC5056 channel binding facility used with
tls-unique-for-telnet channel bindings data for the outer/previous
TLS connection, but it is not a generic-purpose channel binding facility
and may not be used for other channel binding types", plus an
informative reference to RFC5056.

I might support an entirely different proposal, but only if there's
consensus for it amongst implementors, or if there's strong consensus
that a different proposal is more likely to interoperate.  I've to
catch up with a week's worth of e-mail in order to determine which
proposal, if any, and whether any strong arguments have been made about
the [non-]interoperability of the RI proposal (but I suspect there have
not been any).

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Fri, 20 Nov 2009 23:31:19 +0100 (MET)

Joseph Salowey wrote:
> 
> draft-ietf-tls-renegotiation-00
 
I support an entirely different proposal, described here:

http://www.ietf.org/mail-archive/web/tls/current/msg04572.html

and over the weekend I will incorporate this into the I-D that
I'm working.   I will try hard to ship the I-D on Monday 23-Nov-09.

-Martin

---

From: Robert Relyea <[email-masked]>
Date: Fri, 20 Nov 2009 15:11:24 -0800

> - I would support an entirely different proposal (please identify it; be
I support this draft.

bob

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 00:12:07 +0100

I would support an entirely different proposal that supports SSLv3 -> TLS
1.2 using a common approach, I.e. Not using TLS extensions.

The condition is that the implementer community can agree on such approach
within a reasonable timeframe.

In absence of such agreement, I would support this draft.

/Stefan

On 09-11-20 10:53 PM, "Joseph Salowey (jsalowey)" <[email-masked]>
wrote:

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

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 20 Nov 2009 16:06:52 -0800

Here is yet another reason to reject Renegotiation_Info:

The security of RI relies on implementations verifying that the data
carried in the extension is correct.  It is possible for implementors
to get this wrong.  A client or server could correctly get all of the
mechanics of sending and receiving the extension working but fail to
actually compare what they received to the old verify_data.  Looking
at the bits-on-the-wire it will not be possible to tell that a client
or server is broken in this way.  These broken implementations will
be able to perform initial connections and renegotiations.  Such a
broken client paired with a broken server would still be vulnerable
to a MitM attack.

Changing the Finished message calculation, on the other hand, is fool-
proof.  Either you add the old verify_data to the handshake messages
or you don't.  If you don't, then handshakes will fail regularly[*]
and the problem will be noticed and fixed.

Note that adding the verify_data to the ClientHello.random and
ServerHello.random suffers from this same problem.

Mike

[*] To make this even more fool-proof, I suggest making sure that the
data added to the handshake message stream is never empty (i.e. as it
would be on an initial handshake in Martin's proposal); this can be
easily done by including length byte(s) or even a single fixed byte.

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 20 Nov 2009 16:09:10 -0800

It looks like I got scooped by Martin by 4 minutes!  :-)

Mike

---

From: "Robert Dugal" <[email-masked]>
Date: Fri, 20 Nov 2009 19:11:39 -0500

I support this draft

-- 
Robert Dugal		Senior Software Developer
Certicom Corp.		A Subsidiary of Research In Motion 
[email-masked]
direct        905.501.3848
fax             905.507.4230
www.certicom.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph Salowey (jsalowey)
Sent: Friday, November 20, 2009 4:53 PM
To: [email-masked]
Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt

Support for the draft:
- I support this draft

Thanks,

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 20 Nov 2009 17:01:57 -0800

I support using EKR's draft for TLS and an ugly, dirty hack
like those proposed by Michael D'Errico, Martin Rex, and
Nasko Oskov for SSL 3.0.

Wan-Teh Chang

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Nov 2009 02:33:29 +0100 (MET)

> It looks like I got scooped by Martin by 4 minutes!  :-)

I'm sorry.  

It seems that you thought about what it would mean to implement
my newest idea (tunneling verify_data into the handshake message hash
through Hello.Random, somewhat similar to what TLS extension RI does)
and realized this problem.

I had just started to change my I-D that I'm working on and
describe the new idea when I stumbled over this problem.

It was somewhat similar when I was trying to explain to Nico
and Larry that they can not simply ignore that channel bindings
don't carry over through TLS renegotiation, when I realized that
TLS renegotiation would therefore be susceptible to MitM attacks.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Nov 2009 04:01:37 +0100 (MET)

> I'm working.   I will try hard to ship the I-D on Monday 23-Nov-09.

While trying to document the new idea I realized that embedding
the previous finished messages into real handshake messages
leads to a fail UNsafe design just like TLS extenion RI.

So I will stick to what I've been working on through the week
and what Mike has already implemented (manually add verify_data
to the handshake message hash without sending it over the network,
C->S signaling by magic ciphersuite and S->C signaling with
higest bit of ServerHello.server_version.major.

I-D on monday.

-Martin

---

From: Nasko Oskov <[email-masked]>
Date: Sat, 21 Nov 2009 03:15:38 +0000

I support the TLS extension approach for TLS1.0 and above with the modification that we add the magic cipher suite in the client hello. This will allow a TLS ClientHello with the extension to be used against SSLv3 only server (assuming server properly ignores extensions).
For SSLv3 I support Martin Rex's proposal of cipher suite client to server and version bit in server to client.

Nasko

---

From: David-Sarah Hopwood <[email-masked]>
Date: Sat, 21 Nov 2009 04:32:48 +0000

Nasko Oskov wrote:
> I support the TLS extension approach for TLS1.0 and above with the
> modification that we add the magic cipher suite in the client hello.
> This will allow a TLS ClientHello with the extension to be used
> against SSLv3 only server (assuming server properly ignores extensions).

The RI approach can be used with an extension-tolerant SSLv3-only server
even without the "magic ciphersuite".

-- 
David-Sarah Hopwood  ⚥  http://davidsarah.livejournal.com

---

From: Martin Rex <[email-masked]>
Date: Sat, 21 Nov 2009 06:24:01 +0100 (MET)

> even without the "magic ciphersuite".

The RI-approach will not completely prevent connectivity with
an SSLv3-only but extension-tolerant server.

It can, however, _not_ provide any protection either.

In order to get secure renegotiation with an SSLv3-only server
using TLS extension RI, that SSLv3-only server will have to add generic
TLS extension support.

And when that SSLv3-only server does not implement renegotiation,
it will still need to add generic TLS extensions support in order
to assure an updated client using TLS extension RI that it means no harm.

-Martin

---

From: Michael D'Errico <[email-masked]>
Date: Fri, 20 Nov 2009 21:59:53 -0800

I support a different approach, which I documented in this message:

   http://www.ietf.org/mail-archive/web/tls/current/msg04556.html

It is the same as what Martin plans to issue an an Internet-Draft.

I would be fine with modifying it slightly at the suggestion of Dr.
Stephen Henson to have the server return the "magic" cipher suite
in the ClientHello and to put the real cipher suite in the random.
This would avoid difficulties in trying to explain how the version
is modified, but not really modified.

I'm just as upset about needing such a hack as everyone else, but
the installed base has largely ignored extensions, so we can't
responsibly force them on everyone.

Plus, see how the RI extension is critically flawed anyway:

   http://www.ietf.org/mail-archive/web/tls/current/msg04582.html

Mike

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 21 Nov 2009 16:00:26 +0000

> - I would support an entirely different proposal (please identify it; be

I support this draft for fixing TLS.

If another draft emerges in a timely fashion that better addresses
SSL then I might support that as well (either as a separate document
or incorporated into this one). So far I can't tell if an SSL solution
is worthwhile - despite all the words on the list, there's no I-D.

S.

---

From: Florian Weimer <[email-masked]>
Date: Sat, 21 Nov 2009 16:10:20 +0000

> - I support this draft

I support this draft.  The feature in section 4.4.1 should be
included, but my support does not depend on that.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Michael D'Errico <[email-masked]>
Date: Sat, 21 Nov 2009 08:49:12 -0800

Since the tide is going in the direction of this draft, I suggest the
following change to make it fail-safe rather than have the flaw I
pointed out in this message:

The change I propose is simple:

   - the extension is sent on every handshake and is always empty
   - the previous verify_data is added to the Finished calculation
     but not sent over the wire

The latter should be done in the way that we want moving forward to
future versions of TLS.  I have implemented it by putting it in the
handshake message stream immediately following the ServerHello; if
that is undesirable long-term, please suggest an improvement.

Mike

---

From: Dr Stephen Henson <[email-masked]>
Date: Sat, 21 Nov 2009 18:01:44 +0000

> or whether you can live with it unmodified.  

Firstly does this mean the 00 draft or the 01 one?

I've mentioned elsewhere the fact that neither addresses SSLv2 or SSLv3
compatible client hellos (which may well end up talking TLS but they don't know
that initially) and talk of fallbacks doesn't address APIs or libraries that
cannot transparently reconnect.

I'm not really concerned how this is addressed. I would support the 01 draft
with the following modifications:

1. The magic ciphersuite as well as being used as a fallback can be used on
initial connections if the client wishes to send an SSLv2 or SSLv3 compatible
client hello or a TLS one without extensions.

2. Any server which accepts an SSLv2 or SSLv3 compatible client hello MUST be
able to recognise the magic ciphersuite.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Ben Laurie <[email-masked]>
Date: Sat, 21 Nov 2009 11:52:54 -0800

> cannot transparently reconnect.

Which, to be clear, is probably most of them and certainly includes OpenSSL.

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 21 Nov 2009 22:02:09 +0100

I think this is yet another argument for defining the "future" amended
finished calculation now and apply it to both proposals, and simply reduce
the discussion to different ways to do C->S and S->C signaling.

Maybe we could even reduce the discussion to different ways to do S->C
signaling (i.e. Always including the "magic" ciphersuite for C->S) and
perhaps live with different ways of S->C for different protocol versions.

/Stefan

---

From: Yoav Nir <[email-masked]>
Date: Sat, 21 Nov 2009 23:52:01 +0200

> In absence of such agreement, I would support this draft.
 +1

Though I'm not sure why the implementer community (I'm one) would be quicker to agree on any approach than other people.

---

From: Nelson B Bolyard <[email-masked]>
Date: Sat, 21 Nov 2009 21:21:00 -0800

On 2009-11-20 13:53 PST, Joseph Salowey (jsalowey) wrote:
> draft-ietf-tls-renegotiation-00 as a starting point. 

> - I support this draft with the following modification

I support this draft, and request modifications similar to the following,
which (I believe) are merely clarifying in nature, and do not change the
over-the-wire specification any.  I do not require these exact
modifications, but something like them would help a lot.

Page 6 section 3:

-  Upon receipt of the "renegotiation_info" extension, implementations
+  Upon receipt of the "renegotiation_info" extension, both client and
+  server implementations
   which support the extension MUST verify that it contains the correct
   contents as specified above.

Page 6, section 4.1:

-  If a client offers the "renegotiation_info" extension and the server
-  does not respond, then this indicates that the server either does not
+  If a client hello offers the "renegotiation_info" extension (hereinafter
+  abbreviated RI) and the server does not offer an RI extension in the
+  server hello response, then this indicates that the server either does
+  not

Page 7, section 4.2:

-  If the client does not offer the "renegotiation_info" extension, then
+  If the client hello does not offer the "renegotiation_info" extension,
+  and does not contain the "RENEGOTIATE_WITH_RI" cipher suite, then

(Note, this resolves an ambiguity.  Otherwise, the requirements of section
4.2 seem to apply also when "RENEGOTIATE_WITH_RI is present, which section
4.1.1 requires to be dealt with in a different manner.  The suggested change
keeps these requirements of the two sections from overlapping.)

Page 7, section 4.3:

-  SSLv3 does not support extensions and thus it is not possible to Both
+  Both
   SSLv3 (at least later drafts) and TLS 1.0/1.1 require implementations

Page 8, section 4.3 (top of page):

-  extensions since the ordinarily TLS Finished messages protect that
+  extensions since the ordinary TLS Finished messages protect that
   negotiation.

Page 8, section 4.3:

   best practice is not to continue the connection.  Even servers which
-  refuse to renegotiate SHOULD reply with an empty RI extension because
+  refuse to renegotiate SHOULD reply with an empty RI extension in the
+  server hello of the connection's initial handshake because
   this signals that they have been upgraded.

(This clarifies where and when they should reply with that empty RI
extension, since they CANNOT do it in the refused renegotiation.)

Page 8, section 5:

   By default, TLS implementations conforming to this document MUST
-  verify that once an identity has been authenticated within the TLS
-  handshake, it does not change on subsequent renegotiations.
+  verify that once the peer has been identified and authenticated within
+  the TLS handshake, the identity does not change on subsequent
+  renegotiations.

---

From: <[email-masked]>
Date: Sun, 22 Nov 2009 21:10:43 -0500

I support this draft.

------------------------------------------------
Peter Robinson - [email-masked]
Engineering Manager
RSA, The Security Division of EMC - http://www.rsa.com/
Level 32, Waterfront Place, 1 Eagle Street, Brisbane, Queensland 4000, 
AUSTRALIA.
Phone: +61 7 3227 4427, Mobile: +61 407 962 150, Fax: +61 7 3227 4400.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Joseph 
Salowey (jsalowey)
Sent: Saturday, 21 November 2009 7:53 AM
To: [email-masked]
Subject: [TLS] Consensus Call for draft-ietf-tls-renegotiation-00.txt

Support for the draft:
- I support this draft

Thanks,

Joe

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 23 Nov 2009 18:28:24 +1300

>- I would support an entirely different proposal (please identify it; be

I support the (somewhat ongoing) one-size-fits-all signalling + changed-
Finished proposal initiated by Martin.  I can't be too specific at the moment
because it's still evolving, but it seems to be moving in a positive
direction.  It's simpler, more straightforward, and most of all less of a
Russian-roulette game in the face of any number of oddball implementations.

Peter.

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 23 Nov 2009 10:29:08 +0100

> - I would support an entirely different proposal (please identify it; be

I would support Martin Rex's upcoming draft which provides a general
solution that works for both SSLv3 and TLS, instead of using a dirty
hack that only works for TLS.

However I would like to see more analysis of Martin Rex's proposal
before making a decision.  Right now I only see advantages with Martin's
proposal and no disadvantages with it, while I see clear disadvantages
with RI and no advantages with RI that Martin's proposal doesn't also
have.  If that is really the case, Martin's draft will have my support,
but there could be some detail that has been overlooked so far.

/Simon

---

From: "Yngve Nysaeter Pettersen" <[email-masked]>
Date: Mon, 23 Nov 2009 14:28:27 +0100

I support this draft

I may also support a signaling mechanisms that can patch older  
non-extension implementations of SSLv3 and TLS, provided a "good enough"  
solution can be found, but I do not think the search for such a mechanism  
should delay this draft. (I am also inclined to agree with Nelson B.  
Bolyard that it is time to stop being nice to non-compliant servers  
regarding extension intolerance and incorrect version negotiation; we just  
need a date for when the support is turned off)

I also think the finished document should include a timeline for when  
lenient implementations should become strict, and refuse to negotiate with  
unpatched peers. Without such a timeline I think it will take much longer  
to get rid of unpatched implementations (particularly servers) than is  
necessary to get this problem removed from the net. IMO such a timeline  
should not be longer than 12 months from the publication of the RFC.  
Leaving the decision for such a sunset date to vendors is not a good idea  
(just look how long SSLv2 and export ciphers were supported, mostly  
because a few major internet services refused to upgrade).

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 13:57:18 +0100

Yngve Nysaeter Pettersen wrote:

> I also think the finished document should include a timeline for
> when lenient implementations should become strict, and refuse to
> negotiate with unpatched peers. Without such a timeline I think it
> will take much longer to get rid of unpatched implementations
> (particularly servers) than is necessary to get this problem removed
> from the net. IMO such a timeline should not be longer than 12
> months from the publication of the RFC.  Leaving the decision for
> such a sunset date to vendors is not a good idea (just look how long
> SSLv2 and export ciphers were supported, mostly because a few major
> internet services refused to upgrade).

In general, vendors can choose to implement any RFC they want, or can
choose not to do so. And users can choose to deploy some products, or
can choose not to do so.

Although it would be nice if we could just say "everyone SHOULD use
TLS 1.2 (or IPv6, DNSSEC, ...) by end of 2010, and MUST switch off
SSLv3 (or IPv4, NATs, unsigned DNS records, ..) by 2012, that's not
something IETF documents usually say, because it wouldn't have
much effect.

(Or in other words: the incentives for doing or not doing something 
for companies usually come from money, not RFC 2119 key words :-)

Best regards,
Pasi
(not wearing any hats)

---

From: <[email-masked]>
Date: Wed, 25 Nov 2009 14:56:12 +0100

I'm not so sure about the fail-safe argument (either way, the spec
will be very short and simple, and there's not much we can do about
truly incompetent implementors), but I agree this could be better
aligned with future versions of TLS.

Potentially, it could also simplify implementation if you don't
have full TLS extension support (since the extension would always 
be a fixed byte string). And since both parties already know the 
data, we're not really gaining much by sending it over-the-wire...

Best regards,
Pasi
(not wearing any hats)

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext Michael D'Errico
> Sent: 21 November, 2009 18:49
> To: [email-masked]
> Subject: Re: [TLS] Proposed change to draft-ietf-tls-renegotiation-
> 00.txt
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 25 Nov 2009 15:23:20 +0000

Having now read Martin's draft I still think that
draft-ietf-tls-renegotiation is the way to go and
further think that that should be progressed asap.

I would however support the later publication of
a version of draft-mrex-tls-secure-renegotiation
that only addressed old versions not covered by
draft-ietf-tls-renegotiation. The only reason for
"later" here is that I suspect from the list traffic
that finishing that I-D might take a while. I don't
think draft-ietf-tls-renegotiation should wait on
that.

If the above turned out to be the plan then I
guess the magic ciphersuite might no longer be
needed in draft-ietf-tls-renegotiation.

S.

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Nov 2009 09:54:10 -0800

The proposed change (empty extension in both directions on every
handshake + incorporate previous verify_data into new Finished) has
some nice benefits over the current RI proposal:

   - it is simple for clients to add even if they do not currently
     support extensions since all that is needed is to append a
     FIXED 6-byte sequence to ClientHello:  00 04 FF 02 00 00
     (where FF 02 is the new extension number)

   - since a server can only respond with extensions asked for by
     the client, they can either respond with nothing (secure
     renegotiation not supported) or the exact same 6 bytes! (which
     is easy for the client to detect)

   - no need to pack the verify_data into the extension when sending

   - no need to extract the verify_data from the received extension

   - not possible to forget to check that the verify_data is correct
     (since the already-existing Finished check does that)

All of this leads to less code, and is more aligned with what we
want moving into the future.  (Nobody would argue that sending the
old verify_data in an extension would be the preferred way to fix
this for TLS 1.3 would they?)

Mike

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 19:12:43 +0100 (MET)

> some nice benefits over the current RI proposal:

The are currently TLS servers that will send back unsolicited
TLS extensions to the client if a particular ciphersuite (a real one)
is selected.

One of the reasons they're doing this is the lack of support for
sending TLS extensions in the ClientHello on WinXP and Win2003
platforms (for Cryptographic Service Providers).

It's funny that WinXP/Win2003, although not able or willing to
send TLS extensions in ClientHello, do not seem to barf on
unsolicited ServerHelloExtensions in the server's reply,
and instead make it somehow available for the Cryptographic
Service Provider.

So for any solution that involves an extension-less C->S
signaling, and a reply in additional data trailing ServerHello,
this data IMHO _needs_ to be a correctly formatted TLS extension,
and the client must be prepared to receive more than one
unsolicited TLS extension as reply and be able to tell them apart.

I did complain loudly when first heard their server was sending
unsolicited ServerHelloExtensions when that special cipher suite
was negotiated, but I do have a little empathy for their solution.
At least they correctly wrapped it as a TLS extension and did
not just append arbitrary data to ServerHello.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 19:29:51 +0100

Martin,

I feel less concerned about having the clients parse an extension. If they
are already capable of handling one additional extension, it should not be
too hard to handle another.

Especially not if we follow Michael's suggestion and create an empty RI
extension which is easy to add, detect and parse.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 25 Nov 2009 19:34:34 +0100

Stephen,

What you suggest here is not possible following the current proposals.

The magic ciphersuite is needed also in the current draft to prevent
downgrade attacks. If the signaling is present in one draft, another draft
can't change it's meaning.

/Stefan

---

From: Martin Rex <[email-masked]>
Date: Wed, 25 Nov 2009 20:52:54 +0100 (MET)

> extension which is easy to add, detect and parse.

It makes the interop tests a little more difficult.
I don't know how many people do module tests on their code
(I know at least one huge software supplier that doesn't).

When you _newly_ add a generic parser for TLS extension into a
codebase that didn't have it before, and you don't do module tests
(=function api-level testing), then you should use several test cases:

1 (unsolicited) TLS extension, (but not RI)
1 (unsolicited) TLS extension, RI
2 (unsolicited) TLS extension, (but not RI)
2 (unsolicited) TLS extensions,  RI first
2 (unsolicited) TLS extensions,  RI second
3 (unsolicited) TLS extensions,  RI second
3 (unsolicited) TLS extensions,  RI third

which may be something that is difficult to configure with
"stock" TLS servers.

When you do module/functions tests, then doing the test
will be much easier.  Just dump test vectors into the spec. :)

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 26 Nov 2009 14:03:07 +1300

<[email-masked]> writes:

>Although it would be nice if we could just say "everyone SHOULD use TLS 1.2
>(or IPv6, DNSSEC, ...) by end of 2010, and MUST switch off SSLv3 (or IPv4,
>NATs, unsigned DNS records, ..) by 2012, that's not something IETF documents
>usually say, because it wouldn't have much effect.

Just as an extra data point, PKIX documents have occasionally tried this.
Pretty much everyone completely ignored it.

Peter.

---

From: David-Sarah Hopwood <[email-masked]>
Date: Thu, 26 Nov 2009 03:09:08 +0000

> TLS extensions to the client if a particular ciphersuite (a real one)

They should stop doing that. RFC 4366 section 2.3:

#  Note that for all extension types (including those defined in the
#  future), the extension type MUST NOT appear in the extended server
#  hello unless the same extension type appeared in the corresponding
#  client hello.  Thus clients MUST abort the handshake if they receive
#  an extension type in the extended server hello that they did not
#  request in the associated (extended) client hello.

Notice that not only are these servers nonconformant, any client that
does not abort the handshake in response is *also* nonconformant.

> and instead make it somehow available for the Cryptographic

What part of "Thus clients MUST abort the handshake..." do they not
understand?

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Nov 2009 04:57:03 +0100 (MET)

David-Sarah Hopwood wrote:
> They should stop doing that.

Not necessarily -- if they really think they need that extension being sent
back, then they really OUGHT to write it explicitly into their spec (I-D).

> RFC 4366 section 2.3:

That is an obvious defect in rfc4366, because it is too strict.

Even EKR has recently been recently commenting that the wording
of the spec is imperfect and what is more important is the intent.

:
: What about 5246 and unsolicited extensions?
: As far as I can tell, the major argument against using extensions
: for S->C signalling is the 5246 prohibition against the server providing
: unsolicited extensions. However, that was clearly intended to prevent
: the server from sending extensions the client didn't expect and
: that's not the case here. Moreover, we're updating 5246 so we can relax
: the restriction for this extension (though I would think not in general).

If you've been following the discussion about if and how the changing
of identities during renegotiation should be locked down, then you
get an idea how difficult it is to specify a restriction in a fashion
that it does not get in the way of inventions and engineering.

The idea behind the TLS extensions is that they need to be negotiated
before they can be used, otherwise there is no agreement that an option
be used.  This means that in general there is a problem if the server
is the first to mention an Extension, because it lacks the confirmation
from the client.

What the writers of that text did not address is the possibility that
the information from the client to the server might have been implied
by some other option supplied by the client -- like a cipher suite
for example (and there may be real world constraints why the client
was not able to propose the TLS extension himself in ClientHello,
maybe because it is a Crypto Service Provider on WinXP/Win2K3
talking TLS through schannel).

Anyway -- the ugliness with TLS extension was officially started
in rfc-5246 with the semantics of the "signature_algorithm" extension.

Not sending it back in the ServerHello is a bad idea.
ClientHello and ServerHello is the place where all the crypto
parameter negotiation is supposed to happen during the TLS handshake,
and this is where the restriction comes from that one MUST not start
the negotiation on the server side in ServerHello.

If you think that specs are always perfect, always right and
must be followed by the letter, then you know little about specs.
There is no software without a bug and no spec without a defect.

And people who have problem applying common sense to specs are
usually buerocrats, not engineers.

> What part of "Thus clients MUST abort the handshake..." do they not

Pardon me, but that is a pretty bold requirement which
deserves to be ignored when common sense calls for it.

I hear a lot of people complaining about extensions-intolerant
SSLv3 servers, because they close the connection when receiving
something that they do not understand.

Had the rules for TLS extension been set defined with more
common sense describing the intent, then it should have
been obvious that chopping up the signature_algorithms
extension is a bad idea.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 26 Nov 2009 07:43:39 +0200

I support this draft.

I am against the alternative non-extension based implementation for
the following reason. Such solutions, since they are hacks that just
flip existing logic to do something unexpected, will have to carried
on indefinitely in implementations. If TLS 1.3 solves this elegantly
we'll have two codes that solve this problem, one for TLS 1.x, x<=2
and another one for TLS 1.x, x>2. In the long run I don't think that
such solutions are good. Of course it is easier to implement today for
some but I think will turn against implementation sanity in the end.

Given today's trend of the servername extension, is it so important to
talk about an non-extension fix? How big is that target group today?
Is there a figure?

regards,
Nikos

---

From: Bodo Moeller <[email-masked]>
Date: Thu, 26 Nov 2009 21:26:57 +0100

> Firstly does this mean the 00 draft or the 01 one?

This was about draft-ietf-tls-renegotiation-00.txt, which succeeded  
draft-rescorla-tls-renegotiation-01.txt (and has now been succeeded by  
draft-ietf-tls-renegotiation-01.txt).  See http://tools.ietf.org/html/draft-ietf-tls-renegotiation-01 
  for the complete history.

Bodo