Transport Layer Security (tls)

Simon Josefsson | 1 Oct 2009 13:00

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Martin Rex <Martin.Rex <at> sap.com> writes:

> Blumenthal, Uri wrote:
>> 
>> In my understanding, TLS-established server_name should be
>> enforced by the server.
>> 
>> And Martin - I couldn't disagree more with you. The whole point of
>> using TLS is to enforce who can access what. So the client makes sure
>> he accesses the right server, the server makes sure he grants access
>> to the right pages on the right virtual host. And if your server
>> doesn't do that - please kindly tell me what commercial or
>> freeware product it is included in, so I can avoid buying or
>> using it in the future.
>
> There seems to be a significant misunderstanding.
>
> The Host header field of an HTTP request is a detail of an
> application protocol.  The hostname conveyed by the TLS extension
> server name indication (SNI) happens at a competely different
> protocol layer.
>
> The difference becomes obvious when you add reverse proxies
> into the picture (those which terminate the TLS wrapping).
>
> Conceptually, the Host: header field of a HTTP request is
> part of the URL.  If a reverse proxy perform URL rewriting,
> it may as well have to rewrite Host: header fields.  That
> depends entirely on the backend architecture of each
> particular software installation.

(Continue reading)

Blumenthal, Uri | 1 Oct 2009 13:44

Picon

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

I support option (2) and am against option(1), for reasons expressed in earlier emails.

Tnx!

----- Original Message -----
From: Simon Josefsson <simon <at> josefsson.org>
To: martin.rex <at> sap.com <martin.rex <at> sap.com>
Cc: Blumenthal, Uri; tls <at> ietf.org <tls <at> ietf.org>
Sent: Thu Oct 01 07:00:34 2009
Subject: Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Martin Rex <Martin.Rex <at> sap.com> writes:

> Blumenthal, Uri wrote:
>> 
>> In my understanding, TLS-established server_name should be
>> enforced by the server.
>> 
>> And Martin - I couldn't disagree more with you. The whole point of
>> using TLS is to enforce who can access what. So the client makes sure
>> he accesses the right server, the server makes sure he grants access
>> to the right pages on the right virtual host. And if your server
>> doesn't do that - please kindly tell me what commercial or
>> freeware product it is included in, so I can avoid buying or
>> using it in the future.
>
> There seems to be a significant misunderstanding.
>
> The Host header field of an HTTP request is a detail of an
> application protocol.  The hostname conveyed by the TLS extension

(Continue reading)

Yngve Nysaeter Pettersen | 1 Oct 2009 16:01

Picon

Re: rfc4366-bis: Certificate Status for intermediate CA

On Tue, 29 Sep 2009 02:59:23 +0200, Martin Rex <Martin.Rex <at> sap.com> wrote:

> Yngve N. Pettersen wrote:
>>
>> However, sending two CertificateStatusRequest extensions in the same
>> ClientHello is forbidden by RFC 5246 sec 7.4.1.4:
>>
>>     When multiple extensions of different types are present in the
>>     ClientHello or ServerHello messages, the extensions MAY appear in  
>> any
>>     order.  There MUST NOT be more than one extension of the same type.
>
> How about always using the existing extension for the OCSP response
> for the server certificate, and using a new extension for OCSP responses
> for other certificates (like intermediate CA certs), probably unsorted.
>
> PKIs with flat hierarchies (Server-cert signed by self-signed CA cert)
> use only the original extension.  Servers with certs from multi-level
> CA hierarchies need to use the new extension if they want to send
> additional OCSP responses.

If OCSP was the only game in town, to the end of time, that might work,  
but TLS needs to be able to handle other PKI and revocation structures  
than X.509/PKIX and OCSP.

The main problem here, as I understand it, is that the  
CertificateStatusRequest was (or at least gives every appearance to be)  
intended to support *multiple* certificate status methods, not just OCSP.  
Why else use an enum for the type? With the language in RFC 5246 (quoted  
above) and previous versions of Extensions, a client is not able to (in a

(Continue reading)

Martin Rex | 1 Oct 2009 16:54

Picon

Re: rfc4366-bis: Certificate Status for intermediate CA

Martin Rex wrote:
> 
> Yngve N. Pettersen wrote:
> > 
> > However, sending two CertificateStatusRequest extensions in the same  
> > ClientHello is forbidden by RFC 5246 sec 7.4.1.4:
> > 
> >     When multiple extensions of different types are present in the
> >     ClientHello or ServerHello messages, the extensions MAY appear in any
> >     order.  There MUST NOT be more than one extension of the same type.
> 
> How about always using the existing extension for the OCSP response
> for the server certificate, and using a new extension for OCSP responses
> for other certificates (like intermediate CA certs), probably unsorted.
> 
> PKIs with flat hierarchies (Server-cert signed by self-signed CA cert)
> use only the original extension.  Servers with certs from multi-level
> CA hierarchies need to use the new extension if they want to send
> additional OCSP responses.

I mis-explained myself:

Servers would always use the existing TLS extension to convey the
OCSP extension for their end entity cert.  If Servers want to convey
additional OCSP responses (for intermediate CA certs and maybe
from different cert paths), they would additionally have to
use a new extension.

-Martin

(Continue reading)

Joseph Salowey (jsalowey | 1 Oct 2009 18:17

Picon

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

I don't think option 1 is an appropriate change for this document,
although I could be convinced otherwise because I don't think the SHOULD
is very enlightening.  

For option 2 I would prefer text that explains the SHOULD, maybe
something like:

"Since it is possible for a client to present a different server_name in
the application protocol, application server implementations that rely
upon these names being the same MUST check to make sure the client did
not present a different name in the application protocol." 

Joe

> -----Original Message-----
> From: tls-bounces <at> ietf.org [mailto:tls-bounces <at> ietf.org] On 
> Behalf Of Blumenthal, Uri
> Sent: Thursday, October 01, 2009 4:44 AM
> To: 'simon <at> josefsson.org'; 'martin.rex <at> sap.com'
> Cc: 'tls <at> ietf.org'
> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
> (Transport Layer
> 
> I support option (2) and am against option(1), for reasons 
> expressed in earlier emails.
> 
> Tnx!
> 
> 
> ----- Original Message -----

(Continue reading)

Peter Saint-Andre | 1 Oct 2009 18:28

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer


On 10/1/09 10:17 AM, Joseph Salowey (jsalowey) wrote:
> I don't think option 1 is an appropriate change for this document,
> although I could be convinced otherwise because I don't think the SHOULD
> is very enlightening.

I now agree that we need to say something about this in the TLS spec.

> For option 2 I would prefer text that explains the SHOULD, maybe
> something like:
> 
> "Since it is possible for a client to present a different server_name in
> the application protocol, application server implementations that rely
> upon these names being the same MUST check to make sure the client did
> not present a different name in the application protocol." 

+1

Peter

--
Peter Saint-Andre
https://stpeter.im/

Simon Josefsson | 1 Oct 2009 18:49

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

"Joseph Salowey (jsalowey)" <jsalowey <at> cisco.com> writes:

> I don't think option 1 is an appropriate change for this document,
> although I could be convinced otherwise because I don't think the SHOULD
> is very enlightening.  
>
> For option 2 I would prefer text that explains the SHOULD, maybe
> something like:
>
> "Since it is possible for a client to present a different server_name in
> the application protocol, application server implementations that rely
> upon these names being the same MUST check to make sure the client did
> not present a different name in the application protocol." 

I believe that would resolve my concern.

Thanks,
/Simon

> Joe
>
>> -----Original Message-----
>> From: tls-bounces <at> ietf.org [mailto:tls-bounces <at> ietf.org] On 
>> Behalf Of Blumenthal, Uri
>> Sent: Thursday, October 01, 2009 4:44 AM
>> To: 'simon <at> josefsson.org'; 'martin.rex <at> sap.com'
>> Cc: 'tls <at> ietf.org'
>> Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis 
>> (Transport Layer
>>

(Continue reading)

Blumenthal, Uri | 1 Oct 2009 18:41

Picon

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Yes, +1.

----- Original Message -----
From: Peter Saint-Andre <stpeter <at> stpeter.im>
To: Joseph Salowey (jsalowey) <jsalowey <at> cisco.com>
Cc: Blumenthal, Uri; simon <at> josefsson.org <simon <at> josefsson.org>; martin.rex <at> sap.com
<martin.rex <at> sap.com>; tls <at> ietf.org <tls <at> ietf.org>
Sent: Thu Oct 01 12:28:51 2009
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/1/09 10:17 AM, Joseph Salowey (jsalowey) wrote:
> I don't think option 1 is an appropriate change for this document,
> although I could be convinced otherwise because I don't think the SHOULD
> is very enlightening.

I now agree that we need to say something about this in the TLS spec.

> For option 2 I would prefer text that explains the SHOULD, maybe
> something like:
> 
> "Since it is possible for a client to present a different server_name in
> the application protocol, application server implementations that rely
> upon these names being the same MUST check to make sure the client did
> not present a different name in the application protocol." 

+1

(Continue reading)

Martin Rex | 1 Oct 2009 21:08

Picon

Re: Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Joseph Salowey wrote:
> 
> For option 2 I would prefer text that explains the SHOULD, maybe
> something like:
> 
> "Since it is possible for a client to present a different server_name in
> the application protocol, application server implementations that rely
> upon these names being the same MUST check to make sure the client did
> not present a different name in the application protocol." 

OK.  +1

-Martin

Paul Hoffman | 5 Oct 2009 20:17

New draft: draft-solinas-tls-additional-prf-input-00.txt

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>	Title		: Additional PRF Inputs for TLS
>
>	Author(s)	: J. Solinas, P. Hoffman
>	Filename	: draft-solinas-tls-additional-prf-input-00.txt
>	Pages		: 6
>	Date		: 2009-10-5
>	
>This document describes a mechanism for using additional PRF inputs
>   with Transport Layer Security (TLS) and Datagram TLS (DTLS).
>
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-solinas-tls-additional-prf-input-00.txt

Greetings again. We would like to hear input on this draft from the TLS community. The basic idea is an
extension that would allow the two parties to give additional information that is directly mixed into the
master secret through the PRF.

--Paul Hoffman, Director
--VPN Consortium

Group

gmane.ietf.tls.

Search Archive

Page

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10

Articles in period: 92

October 2009

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane

Recent entries

TLS Cached Info Status (14 May 2013)
ECC key exchange messages (8 May 2013)
comments on draft-balfanz-tls-channelid (1 May 2013)
whither draft-agl-tls-nextprotoneg? EncryptedExtensions? (was: Update (30 Apr 2013)
HTTPS vs HTTP Data Increase (23 Apr 2013)
Biggest Fake Conference in Computer Science (27 Apr 2013)
New Revision: draft-ietf-tls-applayerprotoneg-01 Posted (25 Apr 2013)
I-D Action: draft-ietf-tls-applayerprotoneg-01.txt (25 Apr 2013)
draft-mcgrew-tls-aes-ccm-ecc (23 Apr 2013)
AD review of draft-ietf-tls-oob-pubkey (16 Apr 2013)
Protocol Action: 'The TLS Multiple Certificate Status Request Extensio (15 Apr 2013)
TLS CBC ciphersuites fix (14 Apr 2013)
I-D Action: draft-ietf-tls-multiple-cert-status-extension-08.txt (12 Apr 2013)
comments on draft-ietf-tls-applayerprotoneg-00 (10 Apr 2013)
ALPN - specifying client preference (9 Apr 2013)
[Editorial Errata Reported] RFC5054 (3570) (27 Mar 2013)
SCSVs and SSLv3 fallback (4 Apr 2013)
Working Group interest draft-merkle-tls-brainpool-00 (2 Apr 2013)
I-D Action: draft-ietf-tls-multiple-cert-status-extension-06.txt (2 Apr 2013)
draft-ietf-tls-multiple-cert-status-extension-04 (28 Mar 2013)
draft-ietf-tls-cached-info-14 (28 Mar 2013)

Archives

11	May 2013
110	April 2013
165	March 2013
109	February 2013
17	January 2013
48	December 2012
69	November 2012
44	October 2012
32	September 2012
11	August 2012
39	July 2012
52	June 2012
122	May 2012
147	April 2012
123	March 2012
31	February 2012
31	January 2012
69	December 2011
89	November 2011
52	October 2011
147	September 2011
79	August 2011
162	July 2011
22	June 2011
37	May 2011
109	April 2011
114	March 2011
142	February 2011
31	January 2011
20	December 2010
96	November 2010
66	October 2010
78	September 2010
145	August 2010
224	July 2010
226	June 2010
252	May 2010
49	April 2010
133	March 2010
142	February 2010
136	January 2010
547	December 2009
1074	November 2009
92	October 2009
76	September 2009
36	August 2009
94	July 2009
50	June 2009
94	May 2009
120	April 2009
83	March 2009
40	February 2009
18	January 2009
53	December 2008
33	November 2008
106	October 2008
38	September 2008
42	August 2008
66	July 2008
57	June 2008
73	May 2008
59	April 2008
84	March 2008
51	February 2008
84	January 2008
80	December 2007
92	November 2007
84	October 2007
87	September 2007
27	August 2007
144	July 2007
139	June 2007
72	May 2007
6	April 2007
111	March 2007
37	February 2007
204	January 2007
210	December 2006
195	November 2006
81	October 2006
53	September 2006
15	August 2006
68	July 2006
53	June 2006
40	May 2006
33	April 2006
31	March 2006
61	February 2006
32	January 2006
9	December 2005
63	November 2005
45	October 2005
30	September 2005
18	August 2005
6	July 2005
32	June 2005
27	May 2005
28	April 2005
16	March 2005
23	February 2005
39	January 2005
19	December 2004
4	November 2004
4	October 2004
21	September 2004
77	August 2004
12	July 2004
15	June 2004
37	May 2004
32	April 2004
4	March 2004
23	February 2004
44	January 2004
14	December 2003
51	November 2003
13	October 2003
6	September 2003
1	August 2003
6	July 2003
49	June 2003
14	May 2003
12	April 2003
9	March 2003
39	February 2003
16	January 2003
20	December 2002
30	November 2002
20	October 2002
80	September 2002
108	August 2002
5	July 2002
18	June 2002
39	May 2002
36	April 2002

Design

Zawodny | Right Menu | Left Menu

Your Own Design

Paste the URL of your CSS below. Download CSS template