gmane.ietf.certid

Re: Fwd: RFC 6125 on TLS Server ID Check

=JeffH — 2011-03-31T13:57:58

 >>        Title:      Representation and Verification of Domain-Based
 >>                    Application Service Identity within Internet Public
 >>                    Key Infrastructure Using X.509 (PKIX) Certificates
 >>                    in the Context of
 >
 > tl;dr.

by which PeterG sez he means..

  "too long; didn't read."


lol, indeed.

Please note, tho..

1. yes, we overlooked having a short subtitle eg "TLS Server ID Check". mea 
culpa.  (

2. the title is verbose in part to facilitate maximizing hits when folks are 
searching/grep'g thru the RFC Index

3. the spec itself is (too) long due to PKIX/X.509 baroqueness and the variety 
of manners in which various protocols have decided to employ it. Nature of the 
beast and all.


But now the spec is done and all this folklore is finally written down in one 
place (hopefully rather than being re-invented over & over in individual 
protocol specs), and we can go pay attention to newer, hopefully more simple 
stuff (famous last words) e.g. DANE.

Than

Re: Fwd: RFC 6125 on Representation and Verification ofDomain-Based Application Service Identity within InternetPublic KeyInfrastructure Using X.509 (PKIX) Certificates inthe Contextof Transport Layer Security (TLS)

Peter Gutmann — 2011-03-31T00:11:42

tl;dr.

Peter.

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-31T00:07:39

My claim was that including a DNS-ID in the list of reference
identifiers is a necessary condition.  My question of whether the
behavior is actually consistent with the spec stands.


I have nothing more to say on this point except that I will trust your
judgment.  Congratulations on the publication of the RFC.  I look
forward to helping to resolve the issue in a future update, if that is
desired.

Fwd: RFC 6125 on Representation and Verification of Domain-Based Application Service Identity within Internet Public KeyInfrastructure Using X.509 (PKIX) Certificates in the Contextof Transport Layer Security (TLS)

Peter Saint-Andre — 2011-03-30T22:51:22

FYI.

-------- Original Message --------
Subject: RFC 6125 on Representation and Verification of Domain-Based
Application Service Identity within Internet Public KeyInfrastructure
Using X.509 (PKIX) Certificates in the Contextof Transport Layer
Security (TLS)
Date: Wed, 30 Mar 2011 15:33:53 -0700 (PDT)
From: rfc-editor-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org
To: ietf-announce-EgrivxUAwEY< at >public.gmane.org, rfc-dist-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org
CC: rfc-editor-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org


A new Request for Comments is now available in online RFC libraries.


        RFC 6125

        Title:      Representation and Verification of Domain-Based
                    Application Service Identity within Internet Public
                    Key Infrastructure Using X.509 (PKIX) Certificates
                    in the Context of Transport Layer
                    Security (TLS)
        Author:     P. Saint-Andre, J. Hodges
        Status:     Standards Track
        Stream:     IETF
        Da

Re: What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre — 2011-03-30T22:36:04

You are right that, on the inclusion approach, including a DNS-ID in the
list of reference identifiers is the only way to achieve the behavior
you desire. However, in order for the client to vary its behavior based
on the identifiers presented by the server, we would have needed to
modify the spec to use the conditional approach. I'm sure you can
understand that it was simply way too late to perform such major
surgery, two months after IESG approval.

Peter

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-30T22:00:12

I'm not referring to the change in the document.  I meant that the goal
of accepting a DNS-ID in the case that the certificate contains no
SRV-IDs is impossible to achieve unless the (fixed) list of reference
identifiers contains a DNS-ID.  With that clarification, consider my
message.

Re: What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre — 2011-03-30T21:51:17

Ah, I see the confusion. MUST has been changed to SHOULD in order to be
consistent with what I have called the inclusion approach. If we were to
change over to the conditional approach, we could have left DNS-ID as
MUST, but as I said in my previous message that would have required very
significant changes to the spec during AUTH48.

If you'd like I can post the full list of changes, but it is midnight
here in Prague and I have a lot of preparation to do for tomorrow's
working group sessions, so I simply don't have time right now.

Peter

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-30T21:49:58

Sorry, s/first/second/.

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-30T21:45:07

"Prefer" is vague.  Specifically, I would like the client to accept a
DNS-ID if and only if the certificate contains no SRV-IDs.  How is this
accommodated within the framework of the spec?  Clearly the reference
identifier must contain a DNS-ID.  Somehow, this DNS-ID must be
considered to match the presented DNS-ID if and only if the certificate
contains no SRV-IDs.

Section 6.1 says:

   4.  When checking a reference identifier against a presented
       identifier, the client matches the source domain of the
       identifiers and, optionally, their application service type.

Is it within the meaning of "optionally" for the client to elect to
match the service type (thereby preventing two DNS-IDs from matching) if
and only if the certificate contains at least one SRV-ID?  Section 6.5
only describes service type matching in the context of identifiers that
contain service type information.  Is it legitimate to "match the
service type" solely as a means of preventing identifiers that do not
contain service t

Re: What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre — 2011-03-30T21:00:09

I think that this is a matter of local policy -- a client could prefer
SRV-IDs yet still accept DNS-IDs, and as far as I can see that behavior
is not expressly forbidden by the spec.

However, in order to explicitly specify that the client's behavior would
be modified based on what the server presents, we would have needed to
change the entire processing model from what I call the inclusion
approach (if there is an identifier type that you might want to check
then you simply include it in the list of reference identifiers) to what
I call the conditional approach (the client's processing is conditioned
on the presented identifiers that it finds in the server's certificate).
Although Jeff and I considered making that change, the spec has always
been based on the inclusion approach, so modifying it to use the
conditional approach would have necessitated a very significant rewrite
at this late stage in the lifecycle. Jeff and I, and our responsible AD,
were simply not comfortable with performing such major surg

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-30T20:17:14

Unfortunately, this change does not solve the problem.  Consider the
following three client behaviors with respect to presented identifiers:

1. Accept only an SRV-ID.
2. Accept an SRV-ID or a DNS-ID.
3. Accept a SRV-ID, or accept a DNS-ID if there are no SRV-IDs.

Both the old and new versions of the spec allow #1 and #2, but there is
no way consistent with the spec to achieve #3 because the first sentence
of section 6.2.1 requires that the reference identifier list be
independent the presented identifier list.  And #3 is what is required
for existing applications that use DNS-IDs to transition smoothly to
SRV-IDs and achieve the highest level of security supported by both
sides.  Here is why:

- If a new server is to work with old clients, its certificate must
include a DNS-ID as well as a SRV-ID.
- If a new client is to work with old servers, it must accept a
certificate that contains a correct DNS-ID and no SRV-IDs.
- When a new client connects to a new server, it should achieve the
highest level of sec

Re: What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre — 2011-03-30T13:49:15

Hi Matt, thanks again for your feedback. Comments at end.

On 3/19/11 10:05 PM, Matt McCutchen wrote:

You're right. Jeff and I looked at this issue in detail and worked with
our sponsoring AD (Alexey Melnikov) to address it during AUTH48. This
was a bit challenging because we wanted to keep the changeset as small
as possible. Although we considered more significant modifications, we
ended up doing two things in Section 6.2.1 (which defines the rules for
constructing a list of reference identifiers)...

1. Changed MUST to SHOULD for DNS-ID:

###

  Using the combination of fully qualified DNS domain name(s) and
  application service type, the client constructs a list of reference
  identifiers in accordance with the following rules:

  o  The list SHOULD include a DNS-ID.  A reference identifier of type
     DNS-ID can be directly constructed from a fully qualified DNS
     domain name that is (a) contained in or securely derived from the
     inputs (i.e., the source domain), or (b) explicitly associated

Re: What security does SRV-ID add when DNS-ID will always match?

Peter Saint-Andre — 2011-03-20T21:30:00

Agreed.

However, I think that we will probably work on a "bis" version at some
point, so it is good to capture these suggestions.

Peter

Re: What security does SRV-ID add when DNS-ID will alwaysmatch?

Paul Hoffman — 2011-03-19T21:35:24

This document was approved by the IESG months ago and is now in the RFC Editor's queue. It is probably not a good idea to change a major chunk of text at this point.

Re: What security does SRV-ID add when DNS-ID will always match?

Matt McCutchen — 2011-03-19T21:05:31

This is an improvement.  You could just say "if at least one identifier
of type SRV-ID or URI-ID is included in the reference identifier list",
because presumably clients that do not support them will not add them to
the list.

However, you are still forcing the client to decide in advance whether
to require a service type.  Alternatively, the requirement could apply
if at least one reference identifier /and/ at least one presented
identifier contain a service type.  This would realize the general
principle of providing the highest level of security supported by both
sides.  This will be a more realistic client behavior for applications
currently transitioning to the use of SRV-IDs, though it means those
clients do not get any additional security connecting to a service until
all other certificates for that DNS name contain SRV-IDs.  (Note that
clients for the other services need not actually use the SRV-IDs.)
Applications that used SRV-IDs from the beginning can continue to
require a presented SRV-ID.

Pro

Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP

SM — 2011-01-24T21:13:58

Hi Jeff,
At 17:07 21-01-11, =JeffH wrote:

Thanks for clarifying that and for the feedback.

Regards,
-sm

Re: Second Last Call: draft-saintandre-tls-server-id-check (...) to BCP

=JeffH — 2011-01-22T01:07:46

Hi SM,

apologies for latency in replying..

 >>You mean removing the parenthetical "(following the definition of
 >>"label" from [DNS])", yes?
 >>
 >>In reviewing RFC 1035 I see your concern, tho we'd like to reference
 >>a description of "label". I note that RFC 1034 [S3.1] seems to
 >>appropriately supply this, so I propose we keep the parenthetical
 >>but alter it to be..
 >>
 >>   (following the description of labels and domain names in [DNS-CONCEPTS])
 >
 > That's fine to me.

k

 >
 >>Yes, but that definition (and term) appears to be specific to
 >>underlying DNS internals, not to (pseudo) domain names as wielded
 >>(or "presented" (eg in certs)) in other protocols.
 >
 > This brings us to the question of the DNS specific usage of "domain
 > names" and when the term is used in an application context.
 >
 > For example, is the left-most part in "foo*.example.com" (
 > draft-saintandre-tls-server-id-check-12, Section 5.2) acceptable as a label?

No, "foo*" isn't a legit dns label per se. However, it's o

IESG approval of draft-saintandre-tls-server-id-check-14

Peter Saint-Andre — 2011-01-21T02:20:57

During its telechat earlier today, the IESG approved version -14 of
draft-saintandre-tls-server-id-check as a Proposed Standard (not BCP).

I'll leave it to Alexey Melnikov, our sponsoring area director, to
explain the details about where we go from here (e.g., possible
incorporation of small text modifications resulting from the discussion
thread between Matt McCutchen and Jeff Hodges over the last 3 days).

For myself, I fully expect to be working on a bis draft at some point in
the next few years, because I don't think that this I-D is quite the
final word on the topic. However, I do think it brings us closer to wide
consensus regarding application service identity, and that perhaps the
bis draft could be a true BCP (developed, I would think, within the TLS WG).

Thanks to everyone who contributed to and provided feedback on this
document -- your input is very much appreciated!

Peter

Re: What security does SRV-ID add when DNS-ID will always match?

=JeffH — 2011-01-18T19:54:15

 > [...]
 >
 >>  > - The examples of server certificates that include a SRV-ID (section
 >>  > 4.2) also include a DNS-ID
 >>  > - The server ID check succeeds if any reference identifier matches any
 >>  > presented identifier (section 6.3)
 >>  >
 >>  > it would appear that the DNS-IDs will always match, making the service
 >>  > types in the SRV-IDs irrelevant.  Am I right?
 >>
 >> thx for the headsup, but I don't think so, see section 6.5...
 >>
 >> ###
 >>
 >> 6.5. Matching the Application Type Portion
 >>
 >>
 >>     If a client supports checking of identifiers of type SRV-ID and
 >>     URI-ID, it MUST also check the service type of the application
 >>     service with which it communicates (in addition to checking the
 >>     domain name as described above).
 > [...]
 >> ###
 >
 > Maybe I am misunderstanding how that section applies.  Let's consider an
 > example.
 >
 > Reference identifiers:
 > 1. SRV-ID _imaps.example.net
 > 2. DNS-ID example.net

However, according to 3d bullet of S6.3, the client

Re: Fw: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT)

Peter Saint-Andre — 2011-01-18T17:41:04

This will likely be discussed on the IESG telechat this week. However,
Cullen Jennings and Robert Sparks have me convinced that PS is correct.
Jeff and I discussed this with Alexey, too.

Peter

Re: Fw: Lars Eggert's No Objection ondraft-saintandre-tls-server-id-check-14: (with COMMENT)

Matt McCutchen — 2011-01-17T20:59:36

Round we go again...  AIUI, the document needs to be a PS because it
defines matching rules intended for incorporation into application
protocol PSes.  Correct?