Re: [TLS] Consensus call for certificate URL extension

["Mark Tillinghast" <Mark_Tillinghast at symantec.com>]

I support option A

Mark

-----Original Message-----
From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On Behalf Of
tls-request at ietf.org
Sent: Tuesday, September 23, 2008 12:00 PM
To: tls at ietf.org
Subject: TLS Digest, Vol 50, Issue 4

Send TLS mailing list submissions to
	tls at ietf.org

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
	tls-request at ietf.org

You can reach the person managing the list at
	tls-owner at ietf.org

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)" <jsalowey at cisco.com>
Subject: [TLS] Consensus call for certificate URL extension
To: <tls at ietf.org>
Message-ID:
	
<AC1CFD94F59A264488DC2BEC3E890DE5069401B0 at xmb-sjc-225.amer.cisco.com>
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 <ynir at checkpoint.com>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: Joseph Salowey (jsalowey) <jsalowey at cisco.com>
Cc: tls at ietf.org
Message-ID: <6700CFB4-A5F9-42CE-8C28-13524C5A2405 at checkpoint.com>
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 <Martin.Rex at sap.com>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: jsalowey at cisco.com (Joseph Salowey)
Cc: tls at ietf.org
Message-ID: <200809230657.m8N6vIVw007890 at fs4113.wdf.sap.corp>
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" <uri at ll.mit.edu>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "tls at ietf.org" <tls at ietf.org>
Message-ID: <C4FE4ACB.1BDC%uri at ll.mit.edu>
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" <ynir at checkpoint.com> 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
TLS at ietf.org
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 <ekr at networkresonance.com>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "Joseph Salowey (jsalowey)" <jsalowey at cisco.com>
Cc: tls at ietf.org
Message-ID: <20080923134708.EADD76A2B36 at kilo.rtfm.com>
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 <nmav at gnutls.org>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: "Joseph Salowey (jsalowey)" <jsalowey at cisco.com>
Cc: tls at ietf.org
Message-ID: <48D929AB.7030807 at gnutls.org>
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 <mike-list at pobox.com>
Subject: Re: [TLS] Consensus call for certificate URL extension
To: tls at ietf.org
Message-ID: <48D92F56.2090407 at pobox.com>
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
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls


End of TLS Digest, Vol 50, Issue 4
**********************************
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls