headers
Scott Rea | 1 Aug 2012 03:44
Favicon

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)

Permalink | Reply | 5 comments |
headers
Stefan Santesson | 1 Aug 2012 19:56
Favicon

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)

Permalink | Reply | 2 comments |
headers
Peter Saint-Andre | 1 Aug 2012 23:26
Favicon

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)

Permalink | Reply | 0 comments |
headers
Martin Rex | 2 Aug 2012 00:26
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Hannes Tschofenig | 2 Aug 2012 23:54
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)

Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 10 Aug 2012 14:17

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
Permalink | Reply | 0 comments |
headers
Jack Lloyd | 15 Aug 2012 23:40
Gravatar

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)

Permalink | Reply | 0 comments |
headers
Joseph Salowey (jsalowey | 20 Aug 2012 07:07
Picon
Favicon

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)

Permalink | Reply | 0 comments |
headers
Daniel Kahn Gillmor | 29 Aug 2012 21:54

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)

Permalink | Reply | 3 comments |
headers
Adam Langley | 29 Aug 2012 22:08
Picon
Favicon

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

On Wed, Aug 29, 2012 at 3:54 PM, Daniel Kahn Gillmor
<dkg <at> fifthhorseman.net> wrote:
> 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.

DH/ECDH certificates would allow a private key holder to decrypt other
connections made with the same client certificate.

I believe that a signature based (RSA/ECDSA) client certificate is
`safe' as a group authentication method in that one member of the
group could not intercept/decrypt a connection made by another.

"Group signatures" are a problem that has been studied and has a
practical solution:
http://crypto.stanford.edu/~dabo/papers/groupsigs.pdf, although the
bilinear group presents an implementation challenge. ("Group
signatures" in that case are defined to have slightly different
properties, see the paper.)

Cheers

AGL
Permalink | Reply | 1 comment |

Gmane