Subject: Re: [TLS] Consensus call for certificate URL extension

From: "Mark Tillinghast" <[email-masked]>
Date: Tue, 23 Sep 2008 12:04:21 -0700

I support option A

Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, September 23, 2008 12:00 PM
To: [email-masked]
Subject: TLS Digest, Vol 50, Issue 4

Send TLS mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/tls
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of TLS digest..."

Today's Topics:

   1.  Consensus call for certificate URL extension
      (Joseph Salowey (jsalowey))
   2. Re:  Consensus call for certificate URL extension (Yoav Nir)
   3. Re:  Consensus call for certificate URL extension (Martin Rex)
   4. Re:  Consensus call for certificate URL extension
      (Blumenthal, Uri)
   5. Re:  Consensus call for certificate URL extension (Eric Rescorla)
   6. Re:  Consensus call for certificate URL extension
      (Nikos Mavrogiannopoulos)
   7. Re:  Consensus call for certificate URL extension (Mike)

----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Sep 2008 21:52:59 -0700
From: "Joseph Salowey (jsalowey)" <[email-masked]>
Subject: [TLS] Consensus call for certificate URL extension
To: <[email-masked]>
Message-ID:
	
<[email-masked]>
Content-Type: text/plain;	charset="us-ascii"

We need to close this open issue.  I think there are two basic options
that address the security issues that have been raised:

A) Deprecate the current extension and create a similar new extension
with the hash mandatory.

B) Make the hash mandatory in the current extension.  This should not
cause deployment problems because there are no known deployments that
make the hash optional.

In either case, we can include hash agility as described in
http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is support in
the working group for the use case where the certificate is updated
offline then we can possibly work on a new extension in a new document
that incorporates ideas expressed on the list.

Please express you preference on the list for one of these options by
10/6/2008.

Thanks,

Joe

------------------------------

Message: 2
Date: Tue, 23 Sep 2008 09:49:00 +0300
From: Yoav Nir <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: Joseph Salowey (jsalowey) <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes

(B)

I can live with A, but I don't like having deprecated extensions if we  
can avoid them.

On Sep 23, 2008, at 7:52 AM, Joseph Salowey (jsalowey) wrote:

> We need to close this open issue.  I think there are two basic options
> that address the security issues that have been raised:
>
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
>
> B) Make the hash mandatory in the current extension.  This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.
>
> In either case, we can include hash agility as described in
> http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is  
> support in
> the working group for the use case where the certificate is updated
> offline then we can possibly work on a new extension in a new document
> that incorporates ideas expressed on the list.
>
> Please express you preference on the list for one of these options by
> 10/6/2008.
>
> Thanks,
>
> Joe

------------------------------

Message: 3
Date: Tue, 23 Sep 2008 08:57:18 +0200 (MEST)
From: Martin Rex <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: [email-masked] (Joseph Salowey)
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Joseph Salowey wrote:
> 
> We need to close this open issue.  I think there are two basic options
> that address the security issues that have been raised:
> 
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
> 
> B) Make the hash mandatory in the current extension.  This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.
> 
> In either case, we can include hash agility as described in
> http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is support
in
> the working group for the use case where the certificate is updated
> offline then we can possibly work on a new extension in a new document
> that incorporates ideas expressed on the list.
> 
> Please express you preference on the list for one of these options by
> 10/6/2008.

My position is

C)  leave as is, with hash optional
    (and recommend against implementing or deprecating this TLS
extension)

Personally, I don't like this extension, because it creates a lot
of additional complexity and serious vulnerabilities for the server
(DoS of the Server being the mildest aspect).

Why do I NOT like making the hash mandatory?

If a client is able to provide the hash matching the certificate
found under that URL, it should equally be able to include the
certificate itself in the handshake instead of the URL and remove
all problems and vulnerabilities of this extension entirely.

I do NOT want to see that extension being pushed any further,
and making one with the hash mandatory would make it an encoragement.

-Martin

------------------------------

Message: 4
Date: Tue, 23 Sep 2008 07:27:07 -0400
From: "Blumenthal, Uri" <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "[email-masked]" <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

I agree with Yoav and vote for B.

On 9/23/08 02:49 AM, "Yoav Nir" <[email-masked]> wrote:

(B)

I can live with A, but I don't like having deprecated extensions if we
can avoid them.

On Sep 23, 2008, at 7:52 AM, Joseph Salowey (jsalowey) wrote:

> We need to close this open issue.  I think there are two basic options
> that address the security issues that have been raised:
>
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
>
> B) Make the hash mandatory in the current extension.  This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.
>
> In either case, we can include hash agility as described in
> http://trac.tools.ietf.org/wg/tls/trac/ticket/46. If there is
> support in
> the working group for the use case where the certificate is updated
> offline then we can possibly work on a new extension in a new document
> that incorporates ideas expressed on the list.
>
> Please express you preference on the list for one of these options by
> 10/6/2008.
>
> Thanks,
>
> Joe
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

--
Regards,
Uri
<Disclaimer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.ietf.org/pipermail/tls/attachments/20080923/50b74f8a/attachm
ent.htm>

------------------------------

Message: 5
Date: Tue, 23 Sep 2008 06:47:08 -0700
From: Eric Rescorla <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "Joseph Salowey (jsalowey)" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII

At Mon, 22 Sep 2008 21:52:59 -0700,
Joseph Salowey (jsalowey) wrote:
> 
> We need to close this open issue.  I think there are two basic options
> that address the security issues that have been raised:
> 
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
> 
> B) Make the hash mandatory in the current extension.  This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.

(B)

-Ekr

------------------------------

Message: 6
Date: Tue, 23 Sep 2008 20:38:51 +0300
From: Nikos Mavrogiannopoulos <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "Joseph Salowey (jsalowey)" <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Joseph Salowey (jsalowey) wrote:
> We need to close this open issue.  I think there are two basic options
> that address the security issues that have been raised:
> 
> A) Deprecate the current extension and create a similar new extension
> with the hash mandatory.
> 
> B) Make the hash mandatory in the current extension.  This should not
> cause deployment problems because there are no known deployments that
> make the hash optional.

My preference is (B).

------------------------------

Message: 7
Date: Tue, 23 Sep 2008 11:03:02 -0700
From: Mike <[email-masked]>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

>> We need to close this open issue.  I think there are two basic
options
>> that address the security issues that have been raised:
>>
>> A) Deprecate the current extension and create a similar new extension
>> with the hash mandatory.
>>
>> B) Make the hash mandatory in the current extension.  This should not
>> cause deployment problems because there are no known deployments that
>> make the hash optional.

The problem with either of these options is that it gives the impression
that adding the hash improves security.  As I mentioned before, if all a
client does to determine the hash is download the certificate and
compute
its value, then it may just be validating a bogus certificate.

Making the hash mandatory prevents a client from effectively saying, "I
have no idea if the certificate you are about to download is valid."  It
would be much better to leave the hash as optional and to add that a
client MUST NOT send a hash unless it has been configured with it by
some
other means.

Mike

------------------------------

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

End of TLS Digest, Vol 50, Issue 4
**********************************
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Alfred Hönes <[email-masked]>
Date: Thu, 25 Sep 2008 16:53:12 +0200 (MESZ)

At Thu, 25 Sep 2008 09:24:25 +0200 , Simon Josefsson wrote:
> If the assumption in (B), that there are no known deployments of this
> extension, is correct, my preference is to deprecate the extension,
> without creating a new extension with different properties.
> 
> The way I am reading the replies so far imply that few if anyone really
> needs this extension.  If that is the case, I don't see why we need to
> spend time on it.

Under these circumstances, I fully support this variant, '(A-)':
Deprecate the extension.  Full stop.

If we ever want to go for Draft Standard with TLS (I hope we do),
we'll need interoperable implementations anyway, or leave the
Cert URL extension out of the specification (cf. RFC 2026).

So better deprecate it now than later, to save implementation
efforts not really needed now and hence never going to be tested
thoroughly -- another security concern.

Our primary focus now should be to hurry up with 4366-bis, in order to
deliver to the community a consistent set of successors to 4346+4366.

Please recall that TLS 1.2, RFC 5246, already has officially Obsoleted
RFC 4366, increasing the pressure to timely restore a consistent
publication state.
Thus, arguably currently anything in RFC 4366 not incorporated into
RFC 5246 can be regarded as obsoleted anyway, from a very formalistic
point of view.

Pasi has reminded me of my past general input regarding hash
algorithm agility for TLS extensions, which has been tracked
as #46 -- I almost had forgotten that in the meantime!  :-)

Deprecating the Cert URL extension now will solve this problem in
the most time- and sweat-conserving manner possible, leaving the
issue to future work, if any.

If anybody once comes up with a killer need, they can cause a
resurrection of the extension (or the underlying idea), come up
with a new document, plug in algorithms as needed and 'en vogue',
and figure out the security issues.

Best regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+