Scott Rea | 1 Aug 03:44 2012

RFC 6125

We'd like to address a few concerns with RFC 6125.  Because the relevant
discussion list is not active, we contacted the authors and TLS Chair who
instructed us to post our concerns to this list.

Our primary concern with RFC 6125 is that Wildcard certificate use is
wide-spread and has proved to be a cost-effective alternative to
multi-domain certificates.  Asking for the deprecation of wildcard
certificates undermines a lot of existing infrastructure and current
establishments.   We feel that RFC's current recommendations fail to
adequately balance the risks and convenience of an existing practice, is
based only on theoretical problems, and does not accurately reflect current
industry practices or beliefs.

We suggest the following changes to RFC 6125:

-------

Section 1.5 - Overview of Recommendations

[........Edit..................]
Move away from the issuance of so-called wildcard certificates (e.g., a
certificate containing an identifier for "*.example.com").

[........Replace with....]
Follow the established rule set for interpreting wildcard certificates
(e.g., a certificate containing an identifier for "*.example.com").

---------

Section 4.1 - Rules
(Continue reading)

Stefan Santesson | 1 Aug 19:56 2012

Proposed cached info update

I went through the cached info draft and found something in the protocol
syntax that I don't believe is totally correctly expressed.

I made a diff that shows my proposed update:
http://tinyurl.com/cachedinfodiff

The issue at hand is that we use an existing structure to send the cached
info.

The data being replaced is in both cases sent as a vector (single
dimension array) of opaque blobs.
The data being sent instead is a vector of structured cached info elements.

This makes the sending of cached info syntax compatible with the original
syntax as the structured cached info element is compatible with an opaque
blob element.

The current draft and the proposed change is bits on the wire compatible,
it just assigns the vector containing cached info a more sensible name
"cached_objects<1..2^24-1> instead of using the name of the old opaque
vector being replaced (i.e. ASN.1Cert<1..2^24-1> and
DistinguishedName<1..2^16-1>).

I would like those being more experts in the TSL presentation language to
double check me so I don't make a stupid error here.

Thanks

/Stefan
(Continue reading)

Peter Saint-Andre | 1 Aug 23:26 2012

Re: RFC 6125


On 7/31/12 7:44 PM, Scott Rea wrote:
> We'd like to address a few concerns with RFC 6125.  Because the
> relevant discussion list is not active, we contacted the authors
> and TLS Chair who instructed us to post our concerns to this list.
> 
> Our primary concern with RFC 6125 is that Wildcard certificate use
> is wide-spread and has proved to be a cost-effective alternative
> to multi-domain certificates.  Asking for the deprecation of
> wildcard certificates undermines a lot of existing infrastructure
> and current establishments.

RFC 6125 does not deprecate use of the wildcard character '*' in PKIX
certificates. Although Jeff and I would have liked to deprecate such
use, we did not go that far, based on the feedback we received while
working on the document that became RFC 6125.

See Section 4.1:

7.  Unless a specification that reuses this one allows continued
       support for the wildcard character '*', the DNS domain name
       portion of a presented identifier SHOULD NOT contain the wildcard
       character, whether as the complete left-most label within the
       identifier (following the description of labels and domain names
       in [DNS-CONCEPTS], e.g., "*.example.com") or as a fragment
       thereof (e.g., *oo.example.com, f*o.example.com, or
       fo*.example.com).  A more detailed discussion of so-called
       "wildcard certificates" is provided under Section 7.2.

See also Section 6.4.3.
(Continue reading)

Martin Rex | 2 Aug 00:26 2012
Picon

Re: RFC 6125

Scott Rea wrote:
> We'd like to address a few concerns with RFC 6125.  Because the relevant
> discussion list is not active, we contacted the authors and TLS Chair who
> instructed us to post our concerns to this list.
> 
> Our primary concern with RFC 6125 is that Wildcard certificate use is
> wide-spread and has proved to be a cost-effective alternative to
> multi-domain certificates.  Asking for the deprecation of wildcard
> certificates undermines a lot of existing infrastructure and current
> establishments.   We feel that RFC's current recommendations fail to
> adequately balance the risks and convenience of an existing practice, is
> based only on theoretical problems, and does not accurately reflect current
> industry practices or beliefs.

I assure you that the issue of wildcard certs, their usage
has been discussed in quite detail on the cert id mailing
_before_ the document now known as rfc6125 was last called
and published.

(Finding the mailing list archives seems non-trivial, since the
 discussion list itself seems to be no longer listed under
 "non-WG discussion lists" on www.ietf.org)

http://www.ietf.org/mail-archive/web/certid/current/maillist.html

(I realize I should have modified/changed the message subject
 more often...)

A few selected (non-representative!) postings from the discussion
on the certid non-WG IETF mailing list that mention wildcard matching:
(Continue reading)

Eric Rescorla | 2 Aug 20:33 2012

TLS WG Report

The TLS WG met at 10:30 AM on Tuesday:

- TLS-OOB is effectively done. There was discussion of the relationship
   to RFC 6091, which is Informational, but depended upon. Consensus
   is to cut-and-paste the relevant portions. Authors to prepare a new
   draft and WGLC.
http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04

- The CachedInfo draft is ready for WGLC with some minor changes.
  The authors will prepare a new draft.
http://tools.ietf.org/html/draft-ietf-tls-cached-info-12

- The OCSP Multistapling draft needs some more review but is believed
   nearly done. The chairs called for more reviewers of this.
http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-01

- There was a discussion of rollback protection mechanisms (to compensate
for broken servers). The WG agreed to proceed in this line and to discuss
specific mechanisms on-list.

- There was consensus for the WG to accept the TLS-PWD mechanism.
We will confirm on the list.
http://tools.ietf.org/id/draft-harkins-tls-pwd-02.txt

- There was extensive discussion on explicit TLS proxy support (for
proxies which encrypt and decrypt, not RFC 2817 proxies) but
generally the WG seemed not to want to take this work on.
http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-01

-Ekr
(Continue reading)

Hannes Tschofenig | 2 Aug 23:54 2012
Picon
Picon

Re: Proposed cached info update

I agree that this change is useful. 

On Aug 1, 2012, at 10:56 AM, Stefan Santesson wrote:

> I went through the cached info draft and found something in the protocol
> syntax that I don't believe is totally correctly expressed.
> 
> I made a diff that shows my proposed update:
> http://tinyurl.com/cachedinfodiff
> 
> 
> The issue at hand is that we use an existing structure to send the cached
> info.
> 
> The data being replaced is in both cases sent as a vector (single
> dimension array) of opaque blobs.
> The data being sent instead is a vector of structured cached info elements.
> 
> This makes the sending of cached info syntax compatible with the original
> syntax as the structured cached info element is compatible with an opaque
> blob element.
> 
> The current draft and the proposed change is bits on the wire compatible,
> it just assigns the vector containing cached info a more sensible name
> "cached_objects<1..2^24-1> instead of using the name of the old opaque
> vector being replaced (i.e. ASN.1Cert<1..2^24-1> and
> DistinguishedName<1..2^16-1>).
> 
> I would like those being more experts in the TSL presentation language to
> double check me so I don't make a stupid error here.
(Continue reading)

Nikos Mavrogiannopoulos | 10 Aug 14:17 2012

preventing cross protocols attacks -01

Hello,
 I've updated the document proposing protection against cross protocol attacks.
http://tools.ietf.org/search/draft-mavrogiannopoulos-tls-cross-protocol-01

This version references a new cross-protocol attack on TLS described in:
http://www.cosic.esat.kuleuven.be/publications/article-2216.pdf
In that attack a client is vulnerable to a server impersonation
attack, if the server implements the explicit elliptic curve TLS
option.

regards,
Nikos
Jack Lloyd | 15 Aug 23:40 2012
Picon

DTLS 1.2 HelloVerifyRequest version numbers


I'm having a hard time reconciling these statements in RFC 6347 (all
in section 4.2.1):

(a) "[...] DTLS 1.2 server implementations SHOULD use DTLS version 1.0
[in the HelloVerifyRequest] regardless of the version of TLS that is
expected to be negotiated."

(b) "In particular, DTLS 1.2 clients MUST NOT assume that because the
server uses version 1.0 in the HelloVerifyRequest that the server is
not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than
DTLS 1.2."

(c) "The server MUST use the same version number in the
HelloVerifyRequest that it would use when sending a ServerHello.  Upon
receipt of the ServerHello, the client MUST verify that the server
version values match."

Statement (a) says servers should send server_version=1.0 in the
HelloVerifyRequest even if they and the client both support DTLS 1.2,
(b) seems to be saying that a client seeing a HelloVerifyRequest with
server_version=1.0 should not assume the server will eventually
negotiate 1.0, and (c) seems to say that the client must, after having
seen a 1.0 HelloVerifyRequest, reject a ServerHello with version != 1.0

How, then, is it expected for a DTLS 1.2 connection to be negotiated?
The only out I see here is servers ignoring the SHOULD of (a) and
sending DTLS 1.2 in the HelloVerifyRequest if that is what it would
have negotiated from the client hello. And the MUSTs of (b) and (c)
seem to directly contradict each other, so I have to wonder if the
(Continue reading)

Joseph Salowey (jsalowey | 20 Aug 07:07 2012
Picon

Re: Proposed cached info update

I also agree with this change.  Can you submit a new draft with this change and then we can go to working group
last call? 

Thanks,

Joe
On Aug 2, 2012, at 2:54 PM, Hannes Tschofenig wrote:

> I agree that this change is useful. 
> 
> On Aug 1, 2012, at 10:56 AM, Stefan Santesson wrote:
> 
>> I went through the cached info draft and found something in the protocol
>> syntax that I don't believe is totally correctly expressed.
>> 
>> I made a diff that shows my proposed update:
>> http://tinyurl.com/cachedinfodiff
>> 
>> 
>> The issue at hand is that we use an existing structure to send the cached
>> info.
>> 
>> The data being replaced is in both cases sent as a vector (single
>> dimension array) of opaque blobs.
>> The data being sent instead is a vector of structured cached info elements.
>> 
>> This makes the sending of cached info syntax compatible with the original
>> syntax as the structured cached info element is compatible with an opaque
>> blob element.
>> 
(Continue reading)

Daniel Kahn Gillmor | 29 Aug 21:54 2012
Picon

shared secret keys between TLS clients: specific risks? OK in certain suites?

Hi TLS WG--

This is a hypothetical question about an unusual use of TLS, a scenario
which goes against all my instincts about reasonable key management.
I'm hoping for any insight or analysis that might help me understand the
specific risks.

Consider a TLS server that requires client-side key-based
authentication, but doesn't actually need (or want) to know which one of
a group of clients is connecting.

Let's say the operator of this TLS server creates a single secret
asymmetric (RSA or ECDSA or DSA) key (and corresponding X.509
certificate), and shared the same key each one of the group of several
clients.

I'm also fine assuming that both the server and the clients will insist
on negotiating a non-NULL cipher suite (maybe even a specific one if
necessary), are compliant with TLS 1.2, are extension-capable, and
refuse to negotiate down to an earlier version of TLS.

Is there a way that one such client (with a copy of the secret key used
by the client group) could snoop on (or inject traffic into) a
connection established by one of the other clients that share the key?
Or would this depend on the cipher suite selected?  Clearly, at least
PFS in the face of client-key compromise is a pre-requisite here; i note
that several of the existing PFS notes deal with the concept of the
server's secret key being compromised, but don't mention if a
compromised/shared client-side secret key has the same implications.
And of course PFS doesn't itself address the possibility of active
(Continue reading)


Gmane