headers
David Hopwood | 4 May 2002 05:55
Picon

Re: I-D ACTION:draft-ietf-tls-extensions-04.txt


Internet-Drafts <at> ietf.org wrote:
>         Title           : Transport Layer Security (TLS) Extensions
>         Author(s)       : S. Blake-Wilson et al.
>         Filename        : draft-ietf-tls-extensions-04.txt
>         Pages           : 23
>         Date            : 02-May-02

Here are two very minor clarifications that I spotted after the draft was
submitted:

#  - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. For
#     DSA and ECDSA keys, this is the hash of the "subjectPublicKey"
#     value. For RSA keys, the hash is of the byte string
#     representation of the modulus without any initial 0-valued
#     bytes. (This copies the key hash formats deployed in other
#     environments.)

Change to:
      ... For RSA keys, the hash is of the big-endian byte string
      representation of the modulus without any initial 0-valued
      bytes. ...

#      struct {
#          ResponderID responder_id_list<0..2^16-1>;
#          Extensions  request_extensions;
#      } OCSPStatusRequest;
#
#      opaque ResponderID<1..2^16-1>;
#      opaque Extensions<0..2^16-1>;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Povey | 6 May 2002 09:13

Re: I-D ACTION:draft-ietf-tls-extensions-04.txt

>A New Internet-Draft is available from the on-line Internet-Drafts directories
.
>This draft is a work item of the Transport Layer Security Working Group of the
 IETF.
>
>	Title		: Transport Layer Security (TLS) Extensions
>	Author(s)	: S. Blake-Wilson et al.
>	Filename	: draft-ietf-tls-extensions-04.txt
>	Pages		: 23
>	Date		: 02-May-02
>	

Great work.  I noticed the following editorial in Section 2 the 
reference [MAILING LIST] does not exist.

Also I notice the following in section 3.3:

"Server receiving CertificateURL SHALL attempt to retrieve the client's 
certificate chain from the URLs, and the process the certificate chain as 
usual."

Clearly, the server may have cached the certificate from a previous 
exchange, or may have a better cert path for verifying the client's 
identity.  However, the SHALL above does not allow either of these cases.

Changing to SHOULD would help, as at least having the hash of the
certificate around will allow them to make sure their cached copy is fresh
(I guess the text should say something like MAY use a cached copy if a hash
is included in the URI and it matches).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 6 May 2002 09:39
Picon
Picon
Picon
Favicon

Re: Re: I-D ACTION:draft-ietf-tls-extensions-04.txt

Dean Povey <povey <at> wedgetail.com> writes:

>Also I notice the following in section 3.3:
>
>"Server receiving CertificateURL SHALL attempt to retrieve the client's
>certificate chain from the URLs, and the process the certificate chain as
>usual."
>
>Clearly, the server may have cached the certificate from a previous exchange,
>or may have a better cert path for verifying the client's identity.  However,
>the SHALL above does not allow either of these cases.
>
>Changing to SHOULD would help, as at least having the hash of the certificate
>around will allow them to make sure their cached copy is fresh (I guess the
>text should say something like MAY use a cached copy if a hash is included in
>the URI and it matches).

I think it should be even weaker than SHOULD, but for an entirely different
reason: This extension allows any client to tell a server to go to wherever it
(the client) wants and start groping around for data.  The potential security
problems there are quite significant and rather too many to list, and range
from revealing the existence of servers behind firewalls through to allowing a
whole raft of ways of compromising servers by turning them into clients.  I
guess adding text to the effect that "Anyone implementing this deserves
everything they get" would be out of the question?

Peter.

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 6 May 2002 20:42
Picon

Re: Re: I-D ACTION:draft-ietf-tls-extensions-04.txt


Peter Gutmann wrote:
> Dean Povey <povey <at> wedgetail.com> writes:
> 
> >Also I notice the following in section 3.3:
> >
> >"Server receiving CertificateURL SHALL attempt to retrieve the client's
> >certificate chain from the URLs, and the process the certificate chain as
> >usual."
> >
> >Clearly, the server may have cached the certificate from a previous exchange,
> >or may have a better cert path for verifying the client's identity.  However,
> >the SHALL above does not allow either of these cases.

Retrieving something from an URL normally includes the possibility of caching
(either local or proxy caching). As for having a better cert path, that can
be taken into account when "process[ing] the certificate chain as usual", just
as it is when the extension is not used.

> >Changing to SHOULD would help, as at least having the hash of the certificate
> >around will allow them to make sure their cached copy is fresh (I guess the
> >text should say something like MAY use a cached copy if a hash is included in
> >the URI and it matches).

That's an obviously correct optimisation. This draft is intended to go to Last
Call, but if you think it's important, we could clarify this when the RFC is
published, since it doesn't change the intended meaning.

> I think it should be even weaker than SHOULD, but for an entirely different
> reason: This extension allows any client to tell a server to go to wherever it
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dean Povey | 7 May 2002 01:35

Re: I-D ACTION:draft-ietf-tls-extensions-04.txt


>Retrieving something from an URL normally includes the possibility of caching
>(either local or proxy caching). As for having a better cert path, that can
>be taken into account when "process[ing] the certificate chain as usual", just
>as it is when the extension is not used.
>
>> >Changing to SHOULD would help, as at least having the hash of the certifica
te
>> >around will allow them to make sure their cached copy is fresh (I guess the
>> >text should say something like MAY use a cached copy if a hash is included 
in
>> >the URI and it matches).
>
>That's an obviously correct optimisation. This draft is intended to go to Last
>Call, but if you think it's important, we could clarify this when the RFC is
>published, since it doesn't change the intended meaning.

That seems fine to me.  The only issue outstanding is the fact that the
server won't be able to know whether a cert they have in their possesion
uses the same key as the one the client has indicated.  However, this is
enough of an edge case that it probably need not hold up the RFC.

>> I think it should be even weaker than SHOULD, but for an entirely different
>> reason: This extension allows any client to tell a server to go to wherever 
it
>> (the client) wants and start groping around for data.  

I also considered this possibility, but thought that the security 
considerations covered it.  The only issue with this is that the 
recommendations here are whether the feature is on or off, and do not
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Gutmann | 7 May 2002 06:50
Picon
Picon
Picon
Favicon

Re: Re: Re: I-D ACTION:draft-ietf-tls-extensions-04.txt

David Hopwood <david.hopwood <at> zetnet.co.uk> writes:

>Your point about firewalls is a good one, though. How about adding the
>following after "... some security flaw":
>
>  (note that the server may be behind a firewall or otherwise able to access
>  hosts that would not be directly accessible from the public Internet, which
>  may exacerbate this problem)

There's also the secondary problem that even if you're not using it to
attack/probe an internal host (ie it's being used in a not-deliberately-
malicious manner), it can reveal the existence of internal machines which are
otherwise hidden by virtual hosting/masking/NAT/whatever.  That alone may
constitute a security problem.

>>I guess adding text to the effect that "Anyone implementing this deserves
>>everything they get" would be out of the question?
>
>Would it help to strengthen the "It is RECOMMENDED ..." paragraph?:
>
>  Therefore, if the client_certificate_url extension is implemented, it
>  MUST be implemented in such a way that it has to be specifically enabled
>  by a server administrator, rather than being enabled by default.

Is there some general reference which people can be referred to for more
information?  My real concern here is that people will enable this without
really knowing what they're getting into... the MUST above is a good start
though, at least it forces a safe-by-default (and it gives people something to
hit Microsoft over the head with when they ship it enabled by default in
Windows 2005 :-).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kain, Michael T | 9 May 2002 19:53
Picon

TLS question -- Client Key Exchange

In looking at some traces of the TLS and SSL handshakes, the client
key exchange seems to be different.  Using SSL 3.0, the Client Key
Exchange message is either 64 or 128 bytes, but with TLS, it is either
66 or 130...  The specs seem to be identical here.  What causes the
two byte difference?

Mike Kain
System Enabling Software - EDL
Unisys Corporation, Malvern, PA 19355 [Michael.Kain <at> unisys.com]

Adjunct Professor, Math & Computer Science Dept.
Drexel University, Philadelphia, PA 19104 [mkain <at> mcs.drexel.edu] 

---
You are currently subscribed to ietf-tls as: ietf-ietf-tls <at> m.gmane.org
To unsubscribe send a blank email to leave-ietf-tls-5391792O <at> lists.certicom.com
Permalink | Reply | 0 comments |
headers
Eric Rescorla | 10 May 2002 07:18

Re: TLS question -- Client Key Exchange

From the current draft:

-Ekr

 Implementation Note: public-key-encrypted data is represented as an     |
       opaque vector <0..2^16-1> (see S. 4.7). Thus the RSA-encrypted    |
       PreMaster Secret in a ClientKeyExchange is preceded by two length |
       bytes. These bytes are redundant in the case of RSA because the   |
       EncryptedPreMasterSecret is the only data in the                  |
       ClientKeyExchange and its length can therefore be unambiguously   |
       determined. The SSLv3 specification was not clear about the       |
       encoding of public-key-encrypted data and therefore many SSLv3    |
       implementations do not include the the length bytes, encoding the |
       RSA encrypted data directly in the ClientKeyExchange message.     |

       This specification requires correct encoding of the               |
       EncryptedPreMasterSecret complete with length bytes. The          |
       resulting PDU is incompatible with many SSLv3 implementations.    |
       Implementors upgrading from SSLv3 must modify their               |
       implementations to generate and accept the corect encoding.       |
       Implementors who wish to be compatible with both SSLv3 and TLS    |
       should make their implementation's behavior dependent on the      |
       protocol version.                                                 |

--

-- 
[Eric Rescorla                                   ekr <at> rtfm.com]
Author of "SSL and TLS: Designing and Building Secure Systems"
                  http://www.rtfm.com/

---
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 17 May 2002 07:24
Picon

Re: I-D ACTION:draft-ietf-tls-extensions-04.txt


Peter Gutmann wrote:
> David Hopwood <david.hopwood <at> zetnet.co.uk> writes:
> 
> >Your point about firewalls is a good one, though. How about adding the
> >following after "... some security flaw":
> >
> >  (note that the server may be behind a firewall or otherwise able to access
> >  hosts that would not be directly accessible from the public Internet, which
> >  may exacerbate this problem)
> 
> There's also the secondary problem that even if you're not using it to
> attack/probe an internal host (ie it's being used in a not-deliberately-
> malicious manner), it can reveal the existence of internal machines which are
> otherwise hidden by virtual hosting/masking/NAT/whatever.  That alone may
> constitute a security problem.

OK. We'll change it to this:

  Support for client_certificate_url involves the server acting as a
  client in another protocol (usually HTTP, but other URL schemes
  are not prohibited). It is therefore subject to many of the same
  security considerations that apply to a publicly accessible HTTP
  proxy server. This includes the possibility that an attacker might
  use the server to indirectly attack another host that is vulnerable
  to some security flaw. It also includes potentially increased
  exposure to denial of service attacks: an attacker can make
  many connections, each of which results in the server making an
  HTTP request.
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Hopwood | 23 May 2002 18:08
Picon

application/pkix-pkipath


The following template is from the Standards Track I-D
<draft-ietf-tls-extensions-04.txt>, which has just been submitted
for Last Call in the TLS WG. It's intended to be consistent with the
types application/pkix-{cert,crl} from RFC 2585.

(Note: Reply-To is set to the ietf-types list only.)

   To: ietf-types <at> iana.org
   Subject: Registration of MIME media type application/pkix-pkipath

   MIME media type name: application

   MIME subtype name: pkix-pkipath

   Required parameters: none

   Optional parameters: version (default value is "1")

   Encoding considerations:
      This MIME type is a DER encoding of the ASN.1 type PkiPath,
      defined as follows:

         PkiPath ::= SEQUENCE OF Certificate

         PkiPath is used to represent a certification path. Within the
         sequence, the order of certificates is such that the subject of
         the first certificate is the issuer of the second certificate,
         etc.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane