Subject: [secdir] secdir review of draft-saintandre-tls-server-id-check-09

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Sep 2010 17:39:40 -0400

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Please forgive the lateness of this review; I really meant to have it
done sooner.

First, I found the document to be a tough read, and I can't really pin
down why.  I started reviewing it several times, and restarted, before
I finally got through it.  I can't give any advice with this comment,
so just take it as it is.

Second, there's a mixture of "natural person" and "human user" in the
document, and my sense is that you mean the same thing by both.  If
you do, you should switch to one term (I prefer the latter; "natural
person" sounds odd).  If they're meant to be different, you should
make it clear what the difference is.

Third, I'll note the earlier discussion of issues with IDN
comparisons.  I have nothing to add to that discussion, and it may be
that the best thing is to leave things as they are.

Comments are in order of appearance, not significance:

-- Page 16, bullet 6:
       The certificate MAY contain more than one DNS-ID, but SHOULD NOT
       contain more than one CN-ID.

Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's
a question.

-- Page 17, sec 4.2, first graf:
   Before connecting to the server, the client MUST construct a list of
   acceptable reference identifiers.

Why MUST it be done "before"?  Can anyone detect, or does it hurt
interoperability, if it's done, say, in parallel with connection, or
while the client is waiting for the server to return the certificate?

-- Page 18, sec 4.2, last bullet:
   o  The list SHOULD NOT include a CN-ID; however, the CN-ID (if
      included) MUST be constructed only from the source domain and
      never from a target domain.

I find this oddly put.  How about "The list SHOULD NOT include a
CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

I'd also like to take the security note from section 4.3 and echo it
here.  So maybe this?:

<< The list SHOULD NOT include a CN-ID.  If a CN-ID is used despite
this advice, it MUST be constructed only from the source domain and
never from a target domain.  Further, it MUST NOT be used unless there
are no other supported identifiers present in the certificate. >>

-- Page 18, sec 4.3, first graf:
   by seeking a match and aborting the search if any presented
   identifier matches one of its reference identifiers.

"Aborting" has the connotation of premature termination, before
completion, and that's not the case here; you're saying that the match
completes the process.  How about, simply, "stopping", or "ending" ?

-- Page 19, sec 4.4.3:
I think implementers might think that you're simply allowing any
leading wildcard character, so we should explicitly dissuade them.

So, in the first graf:
   the wildcard character '*', but only as the left-most label of the
   domain name,
make it "only as the complete value of the left-most label".

And in the second graf:
   in which the wildcard character is contained within a label fragment
   (e.g., baz*.example.net is not allowed and MUST NOT be taken to match
   baz1.example.net and baz2.example.net)
change to:
   baz1.example.net and baz2.example.net; also, *bozz.example.net is
   not allowed and MUST NOT be taken to match frobozz.example.net)

-- Page 19, sec 4.4.3, last graf:
   A specification that references the rules defined in this document
   can specify that the wildcard character is not allowed in
   certificates used by the relevant application protocol or community
   of interest.

How about “...can strengthen this section by ruling out wildcard
matching altogether for the relevant...” ?

-- Page 20, sec 4.4.4, second graf:
   entry types supported by the client), the client MAY as a fallback
   check for a string whose form matches that of a fully-qualified DNS
   domain name in the CN-ID.

Back in section 4.2, you say that the client SHOULD NOT include CN-ID
in the list, and here you're saying that it MAY make such a
comparison.  That seems oddly contradictory to me, though one can
certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this
worded differently.

-- Page 21, sec 4.6.2:
   client MUST verify that the presented certificate matches the cached
   certificate and (if it is an interactive client) MUST notify the user
   if the certificate has changed since the last time a secure
   connection was successfully negotiated (where causes of change
   include but are not limited to changes in the DNS domain name,
   identifiers, issuer, certification path, and expiration date).

I worry about this kind of advice.  It violates my rule that says,
"Don't ask the user a question that he's not qualified to answer."  Of
course, "notify the user" can mean a lot of things, but too many
clients will implement something like this with a popup that will be
meaningless to 99% of the people who use it.

-- Page 21, sec 4.6.3, last graf:
   Instead, the client MUST proceed as follows.

I like a colon there, instead of the full stop.

-- Page 21, sec 4.6.3.1, security note:
      caution, for example by first encouraging the user to terminate
      the connection, forcing the user to view the entire certification
      path, and allowing the user to accept the certificate only on a
      temporary basis (i.e., for this connection attempt and all
      subsequent connection attempts for the life of the application
      session).

Same comment as for 4.6.2.  Most users will not understand certificate
problems, and will have no idea what they should do about them.
Always remember the "Barry's mother problem".  My mother will *never*
want to see an "entire certification path", let alone appreciate being
"forced" to.

-- Page 22, sec 5.1:
   When the connecting application is an interactive client, the source
   domain name and service type MUST be provided by a human user (e.g.
   when specifying the server portion of the user's account name on the
   server or when explicitly configuring the client to connect to a
   particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
   the user inputs in an automated fashion (e.g., a host name or domain
   name discovered through DNS resolution of the source domain).  This
   rule is important because only a match between the user inputs (in
   the form of a reference identifier) and a presented identifier
   enables the client to be sure that the certificate can legitimately
   be used to secure the connection.

Does this mean that a client specifically designed for the "gumbo"
service can't automatically use the service type "gumbo", without the
user's involvement?  Or that a client put out by example.net can't
assume a host name of services.example.net in the absence of user
input that says otherwise?

Further, it's entirely reasonable for a program to have a user enter
something like "gmail", and have the client turn that into something
like "mail.google.com", deriving it from the user's input in an
automated fashion.  Do we really want to forbid that sort of thing?

--
Barry Leiba

---

From: Barry Leiba <[email-masked]>
Date: Wed, 22 Sep 2010 12:34:50 -0400

Hi, Peter.  Thanks for the response, and I'm very happy with nearly
all the changes you've adopted.  I'll not quote and comment on it all,
except to make the general statement: Great work!

> The last sentence does not apply in Section 4.2, because that section
> concerns construction of the list of reference identifiers and as stated
> above the client needs to do so without being influenced by the contents
> of the certificate presented by the server.

I see your point, and I agree.
Still, it might be useful at this point to explain WHY the list SHOULD
NOT include a CN-ID.  I'll leave it there, with no further argument...
it's certainly explained later, so perhaps that's good enough, and
there's no reason to spend further time on this here.

> Note that the "MUST NOT" above is a hypothetical ("MUST NOT ... if").
> Jeff is a bit uncomfortable with that because CN-ID is such a common
> practice, but I'm comfortable with it because of the hypothetical nature
> of the recommendation. He will review the earlier discussions on this
> topic before we finalize that text.

I agree with you, Peter: I think the text is fine as you've given it.

> The part of the text that you have not quoted does say that this
> practice is typically offered only to advanced users (and I don't think
> that Barry's mother counts as an advanced user).

True; I'd missed that point, and I'm happy with the newer, scarier text.

The only point I still want to push on is this one:

> IMHO that is a matter of user configuration, or user acknowledgement of
> a service agreement, so it falls under the text in this I-D about
> allowing the client to check the certificate against a DNS domain name
> that is explicitly associated with the source domain by means of user
> configuration.
>
> Yes, we do, because although you happen to "just know" that
> mail.google.com is a legitimate DNS domain name to connect to when
> interacting with the gmail.com service, Barry's mother might not have
> that kind of knowledge and as a general rule it's a very bad idea to
> assume that it's just fine to connect to some domain at foo.com when
> interacting with a service at bar.com. However, service delegation is a
> difficult topic and there are ongoing discussions among various IETF
> participants about how to do service delegation securely; one thing I
> think we can safely say is that it's not the task of this I-D to solve
> the problem of secure service delegation.

There's a distinction, here, between a protocol and a user interface
for configuration.  My mother doesn't know whom to trust, except that
she knows that she (at least kinda-sorta) trusts the mail program
she's decided to use, and an entity she calls "gmail" (not
"google.com", not "gmail.com", but just "gmail").  She's relying to
the mail program's "easy configuration feature" to sort this out.

The text I reviewed appeared to be saying normative things about what
client software MUST and MUST NOT do with regard to this sort of
configuration situation, which goes well beyond what the client
software is doing on the wire.  Unless I'm mis-reading it, it's
explicitly saying that my client software is not allowed to do
something like this, for example:
1. Ask the user, "What email service do you use?"
2. Receive the answer "gmail" from the user.
3. Auto-configure itself for the known gmail servers based only on
that user input.

If I am, indeed, misreading it, please tell me... and perhaps tweak
the wording to make it less likely that someone else will misread it
the same way.

Again, this is my only remaining quibble with the document, and,
again, it's a very good piece of work.

Barry

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Sep 2010 14:14:01 -0400

> 3. Auto-configure itself for the known gmail servers based only on

I think that's reasonable behavior _if_ the mail client knows that "gmail" 
is "mail.google.com".  What's _not_ reasonable is for it to arbitrarily 
transform "gmail" into a domain by adding ".com", then look up "gmail.com" 
and see that it is an alias for "mail.google.com" and not only follow the 
(insecure) alias to mail.google.com but also use it to decide that 
"mail.google.com" is an appropriate name to find in a certificate.

If your mother's mail client does that, then all I have to do to steal her 
password is convince said client that "gmail.com" is actually an alias for 
"stealgmailpassword.attacker.org".

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 23 Sep 2010 14:10:48 -0400

There is no black magic here, only the magic of the TLS server_name  
extension.  If the client provides server_name=gmail.com, the server  
provides a gmail.com cert, otherwise it defaults to mail.google.com.   
Your browser is following two secure delegations before it lands at www.google.com 
  (gmail.com -> mail.google.com -> www.google.com).  My guess based on  
the anecdotes in the thread is that IE8 doesn't support it.

(You should also be more careful about your HTTP emulation! "A client  
MUST include a Host header field in all HTTP/1.1 request messages .")

In full detail:

rbarnes$ openssl s_client -connect gmail.com:443 -servername gmail.com
[...]
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=gmail.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority
[...]

GET / HTTP/1.1
Host: gmail.com

HTTP/1.1 301 Moved Permanently
Location: https://mail.google.com/mail/
[...]

rbarnes$ openssl s_client -connect mail.google.com:443 -servername  
mail.google.com
[...]
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ 
CN=mail.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
[...]

GET /mail/ HTTP/1.1
Host: mail.google.com

HTTP/1.1 302 Moved Temporarily
Location: https://www.google.com/accounts/ServiceLogin?service=mail&passive=true&rm=false&continue=https%3A%2F%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy%3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1&ltmpl=default&ltmplcache=2
[...]

rbarnes$ openssl s_client -connect www.google.com:443 -servername www.google.com
[...]
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
[...]

GET /accounts/ServiceLogin? 
service=mail&passive=true&rm=false&continue=https%3A%2F 
%2Fmail.google.com%2Fmail%2F%3Fui%3Dhtml%26zy 
%3Dl&bsv=1eic6yu9oa4y3&ss=1&scc=1&ltmpl=default&ltmplcache=2 HTTP/1.1
Host: www.google.com

HTTP/1.1 200 OK
[...]

On Sep 22, 2010, at 3:37 PM, Marsh Ray wrote:

> On 09/22/2010 01:31 PM, ArkanoiD wrote:
>> BTW, slightly offtopic here: whenever i connect to gmail.com, i get  
>> certificate
>> for mail.google.com. But i've yet to see any web browser to  
>> complain! Where is the magic?
>
> Seems totally relevant to me.
>
> Going to https://gmail.com/ I get some kind of redirection to https://www.google.com/accounts/ServiceLogin 
> ...
>
> I can confirm the silent redirect behavior on FF, an associate  
> reports it on IE9. I tried IE8 but get the expected "cert was issued  
> for a different website's address" error.
>
> Hopefully I'm overlooking something simple, but at first glance it  
> would seem like either of these two conditions are true:
>
> 1. Multiple vendors are putting some kind of override table in their  
> browsers with an entry for gmail.com.
>
> 2. Browsers are running script from badly authenticated sources.
>
> So what does gmail.com have in this situation that an attacker  
> couldn't obtain for phonygmail.com?
>
> - Marsh
>
>
> marsh@lamb:/tmp$ dig -t any gmail.com
>
> ; <<>> DiG 9.7.0-P1 <<>> -t any gmail.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44091
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 2
>
> ;; QUESTION SECTION:
> ;gmail.com.			IN	ANY
>
> ;; ANSWER SECTION:
> gmail.com.		300	IN	A	74.125.227.22
> gmail.com.		300	IN	A	74.125.227.21
> gmail.com.		300	IN	A	74.125.227.24
> gmail.com.		300	IN	A	74.125.227.23
> gmail.com.		86400	IN	NS	ns4.google.com.
> gmail.com.		86400	IN	NS	ns1.google.com.
> gmail.com.		86400	IN	SOA	ns1.google.com. dns-admin.google.com.  
> 1427981 21600 3600 1209600 300
> gmail.com.		3600	IN	MX	40 alt4.gmail-smtp-in.l.google.com.
> gmail.com.		3600	IN	MX	5 gmail-smtp-in.l.google.com.
> gmail.com.		3600	IN	MX	20 alt2.gmail-smtp-in.l.google.com.
> gmail.com.		300	IN	TXT	"v=spf1 redirect=_spf.google.com"
>
> ;; ADDITIONAL SECTION:
> ns4.google.com.		85092	IN	A	216.239.38.10
> ns1.google.com.		85092	IN	A	216.239.32.10
>
> ;; Query time: 54 msec
> ;; SERVER: 192.168.1.3#53(192.168.1.3)
> ;; WHEN: Wed Sep 22 14:26:29 2010
> ;; MSG SIZE  rcvd: 330
>
>
>
> marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443
> ...
> subject=/C=US/ST=California/L=Mountain View/O=Google Inc/ 
> CN=mail.google.com
> issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
> ...
> ---
> GET / HTTP/1.0
>
> HTTP/1.0 200 OK
> Date: Wed, 22 Sep 2010 19:31:43 GMT
> Expires: -1
> Cache-Control: private, max-age=0
> Content-Type: text/html; charset=ISO-8859-1
> Set-Cookie:  
> PREF 
> =ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7;  
> expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com
> Set-Cookie:  
> NID 
> = 
> 39 
> = 
> nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i 
> -CvhRU1DrDDYvExygPnpew69GRLaWZeI0; expires=Thu, 24-Mar-2011 19:31:43  
> GMT; path=/; domain=.google.com; HttpOnly
> Server: gws
> X-XSS-Protection: 1; mode=block
>
> <!doctype html><html><head><meta http-equiv="content-type"  
> content="text/html; charset=ISO-8859-1"><title>Google</ 
> title 
> > 
> < 
> script 
> >window.google={kEI:"n1maTNKCA5O8zAXDpJFW",kEXPI:"24956,26758",kCSI: 
> {e 
> :"24956,26758 
> ",ei:"n1maTNKCA5O8zAXDpJFW",expi:"24956,26758"},ml:function() 
> {},kHL:"en",time:function(){return(new  
> Date).getTime()},log:function(b,d,c){var a=new  
> Image 
> ,e=google,g=e.lc,f=e.li;a.onerror=(a.onload=(a.onabort=function() 
> {delete g[f]}));g[f]=a;c=c||"/gen_204?atyp=i&ct="+b+"&cad="+d 
> +"&zx="+google.time();a.src=c;e.li=f+1},lc:[],li:0,Toolbelt:{}};
> window.google.sn="webhp";window.google.timers={load:{t:{start:(new  
> Date).getTime()}}};try{}catch(u){}window.google.jsrt_kill=1;
> var _gjwl=location;function _gjuc(){var  
> e=_gjwl.href.indexOf("#");if(e>=0){var  
> a=_gjwl.href.substring(e);if(a.indexOf("&q=")>0||a.indexOf("#q=")>=0) 
> {a=a.substring(1);if(a.indexOf("#")==-1){for(var c=0;c<a.length;) 
> {var d=c;if(a.charAt(d)=="&")++d;var  
> b=a.indexOf("&",d);if(b==-1)b=a.length;var  
> f=a.substring(d,b);if(f.indexOf("fp=")==0){a=a.substring(0,c) 
> +a.substring(b,a.length);b=c}else if(f=="cad=h")return  
> 0;c=b}_gjwl.href="/search?"+a+"&cad=h";return 1}}}return 0}function  
> _gjp(){!(window._gjwl.hash&&
> window._gjuc())&&setTimeout(_gjp,500)};
> window._gjp && _gjp()</script><style id=gstyle>body{margin: 
> 0}#gog{padding:3px 8px 0}td{line-height:.8em}.gac_m td{line-height: 
> 17px}form{margin-bottom:20px}body,td,a,p,.h{font-family:arial,sans- 
> serif}.h{color:#36c;font-size:20px}.q{color:#00c}.ts td{padding: 
> 0}.ts{border-collapse:collapse}em{font-weight:bold;font- 
> style:normal}.lst{width:496px}.tiah{width:458px}input{font- 
> family:inherit}a.gb1,a.gb2,a.gb3,a.gb4{color:#11c ! 
> important}#gog{background:#fff}#gbar,#guser{font-size:13px;padding- 
> top:1px !important}#gbar{float:left;height:22px}#guser{padding- 
> bottom:7px !important;text-align:right}.gbh,.gbd{border-top:1px  
> solid #c9d7f1;font-size:1px}.gbh{height:0;position:absolute;top: 
> 24px;width:100%}#gbs,.gbm{background:#fff;left: 
> 0;position:absolute;text-align:left;visibility:hidden;z-index: 
> 1000}.gbm{border:1px solid;border-color:#c9d7f1 #36c #36c #a2bae7;z- 
> index:1001}.gb1{margin-right:.5em}.gb1,.gb3{zoom: 
> 1}.gb2{display:block;padding:.2em .5em}.gb2,.gb3{text- 
> decoration:none;border- 
> bottom:none}a.gb1,a.gb2,a.gb3,a.gb4{color:#00c ! 
> important}a.gb2:hover{background:#36c;color:#fff ! 
> important}#gbar{display: none}#gbe{display:  
> none}body{background:#fff;color:black}input{-moz-box-sizing:content- 
> box}a{color:#11c;text-decoration:none}a:hover,a:active{text- 
> decoration:underline}.fl  
> a{color:#4272db}a:visited{color:#551a8b}a.gb1,a.gb4{text- 
> decoration:underline}a.gb3:hover{text-decoration:none}#ghead  
> a.gb2:hover{color:#fff!important}.ds{display:-moz-inline- 
> box}.ds{border-bottom:solid 1px #e7e7e7;border-right:solid 1px  
> #e7e7e7;display:inline-block;margin:3px 0 4px;margin-left: 
> 4px}.sblc{padding-top:5px}.sblc a{display:block;margin:2px 0;margin- 
> left:13px;font-size:11px;}.lsbb{background:#eee;border:solid  
> 1px;border-color:#ccc #999 #999 #ccc;height: 
> 30px;display:block}.lsb{background:url(/images/srpr/nav_logo14.png)  
> bottom;font:15px arial,sans- 
> serif;border:none;color:#000;cursor:pointer;height:30px;margin: 
> 0;outline:0;vertical- 
> align:top 
> }.lsb:active{background:#ccc}.lst:focus{outline:none}.ftl,#fll  
> a{margin:0 12px}#addlang a{padding:0 3px}.gac_v  
> div{display:none}.gac_v .gac_v2,.gac_bt{display:block!important}</ 
> style><script>google.y={};google.x=function(e,g) 
> {google.y[e.id]=[e,g];return false};window.gbar={qs:function() 
> {},tg:function(e){var o={id:'gbar'};for(i in  
> e)o[i]=e[i];google.x(o,function(){gbar.tg(o)})}};</script></ 
> head><body bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b  
> alink=#ff0000 onload="document.f.q.focus();if(document.images)new  
> Image().src='/images/srpr/nav_logo14.png'" ><textarea id=csi  
> style=display:none></textarea><iframe name=wgjf style=display:none></ 
> iframe><div id=ghead><div id=gog><div id=guser  
> width=100%><nobr><span id=gbn class=gbi></span><span id=gbf  
> class=gbf></span><span id=gbe><a href="/url?sa=p&pref=ig&pval=3&q=http://www.google.com/ig%3Fhl%3Den%26source%3Diglk&usg=AFQjCNFA18XPfgb7dKnXfKz7x7g1GDH1tg 
> " class=gb4>iGoogle</a> | </span><a href="/preferences?hl=en"  
> class=gb4>Search settings</a> | <a href="https://www.google.com/accounts/Login?hl=en&continue=https://www.google.com/ 
> " class=gb4>Sign in</a></nobr></div><div class=gbh style=left:0></ 
> div><div class=gbh style=right:0></div></div></div> <center><br  
> clear=all id=lgpd><div id=lga><img src="images/logos/ 
> ssl_logo_lg.gif" width=276 height=110 border=0><br></div><font  
> size=-1>Go to <a href="http://www.google.com/">classic Google</a>.</ 
> font><form action="/search" name=f><table cell
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 09:59:12 -0600

Barry, thank you for your review. Jeff and I are working through all the
feedback that's been provided so far, and we'll be replying in various
threads and cc'ing all appropriate lists as we (the editorial team)
reach agreement on how to proceed.

> so just take it as it is.

Thanks for the feedback. The subject-matter is more dense than one might
expect, and we attempted to be as thorough as possible so as to remove
ambiguities. As a way of orienting the reader, we are thinking about
adding a paragraph or two to the introduction briefly outlining our
conclusions, but we don't yet have text to propose.

> make it clear what the difference is.

In our working copy we've changed "natural person" to "human user" in
all instances.

> that the best thing is to leave things as they are.

IDN-related topics are indeed always challenging, but we think that the
current text meets the needs of this specification.

> Why "SHOULD NOT", and not "MUST NOT" ?  I'm not challenging this; it's

In an earlier version of this specification, we had "MUST NOT" instead
of "SHOULD NOT". Discussion on the [email-masked] list led us to change
it to "SHOULD NOT", because folks argued that if a certificate contains
multiple DNS-IDs then it might appropriately contain one CN-ID
corresponding to each DNS-ID. Jeff said he needs to review the older
discussion again before the editors agree on how to proceed.

> while the client is waiting for the server to return the certificate?

The current wording is unfortunate, because it is not temporal order
that matters; what matters is that the client constructs its list of
reference identifiers without being influenced by the presented
identifiers provided in the certificate that's being checked.

Therefore Jeff and I propose the following corrected text:

   Based on the source domain and the type of service to which
   the client is connecting, the client MUST construct a list of
   acceptable reference identifiers.

> CN-ID.  If a CN-ID is used despite this advice, it MUST be..." ?

We have changed it to:

   o  The list SHOULD NOT include a CN-ID; however, if a CN-ID is
      included despite this advice, it MUST be constructed only from
      the source domain and never from a target domain.

> completes the process.  How about, simply, "stopping", or "ending" ?

In our working copy, that paragraph now reads:

   Once the client has constructed its list of reference identifiers and
   has received the server's presented identifiers in the form of a PKIX
   certificate, the client checks its reference identifiers against the
   presented identifiers for the purpose of finding a match.  The search
   fails if the client exhausts its list of reference identifiers
   without finding a match.  The search succeeds if any presented
   identifier matches one of the reference identifiers, at which point
   the client SHOULD stop the search.

>    not allowed and MUST NOT be taken to match frobozz.example.net)

We've tightened up that text, as follows:

###

   A client employing this specification's rules MAY match the reference
   identifier against a presented identifier in which a traditional
   domain name or internationalized domain name contains one instance of
   the wildcard character '*', but only if that character is the
   complete left-most label of the domain name (as "label" is defined in
   [DNS]).  The following rules apply:

   1.  The client MUST NOT match a presented identifier in which the
       wildcard character is not the only character of the label; e.g.,
       baz*.example.net and *baz.example.net and b*z.example.net are not
       allowed and MUST NOT be taken to match baz1.example.net and
       foobaz.example.net and buzz.example.net.

   2.  The client MUST NOT match a presented identifier in which the
       wildcard character comprises a label other than the left-most
       label; e.g., bar.*.example.net is not allowed.

   3.  The client MUST compare the wildcard character only against the
       left-most label; e.g., *.example.com matches foo.example.com but
       not bar.foo.example.com or example.com.

###

> matching altogether for the relevant...” ?

Changed in our working copy to:

   A specification that references the rules defined in this
   document can strengthen the generic recommendations herein
   by disallowing wildcard matching altogether for the relevant
   application protocol or community of interest.

> certainly argue that SHOULD NOT implies MAY.  I'd prefer to see this

Good catch.

Jeff and I do indeed mean to say that CN-ID is NOT RECOMMENDED, not that
it is OPTIONAL (the two are not equivalent, as I recently learned by
re-reading RFC 2119). Therefore we have provisionally modified the text
in Section 4.4.4 to read:

   As noted, a client MUST NOT seek a match for a reference identifier
   of CN-ID if the presented identifiers include an SRV-ID, URI-ID,
   DNS-ID, or any application-specific subjectAltName entry types
   supported by the client.

   Therefore, if and only if the set of identifiers does not include a
   subjectAltName entry of type dNSName, SRVName, or
   uniformResourceIdentifier (or any application-specific subjectAltName
   entry types supported by the client), as a fallback the client is
   allowed to check the CN-ID for a string whose form matches that of a
   fully-qualified DNS domain name.  Despite the fact that this
   behavior is NOT RECOMMENDED, if the client does compare a
   reference identifier of type CN-ID against that string obtained from
   a CN-ID presented in the certificate, it MUST follow the comparison
   rules for the source domain of an identifier of type DNS-ID, SRV-ID,
   or URI-ID, as described under Section 4.4.

> meaningless to 99% of the people who use it.

Based on feedback from other threads, that section now reads:

###

4.6.2.  Case #2: No Match Found, Cached Certificate

   If the client finds no presented identifier that matches any of the
   reference identifiers but a human user has permanently accepted the
   certificate during a previous connection attempt or via configured
   preferences, the certificate has already been cached.  In this case,
   the client MUST verify that the presented certificate matches the
   cached certificate; if the presented certificate does not match the
   cached certificate then the client MUST proceed as described under
   Case #3 below.

###

See also our reply below regarding Section 4.3.6.1.

> I like a colon there, instead of the full stop.

I used to like colons in such places, but I've migrated to full stop.
We'll see what the RFC Editor has to say. :)

The part of the text that you have not quoted does say that this
practice is typically offered only to advanced users (and I don't think
that Barry's mother counts as an advanced user). However, we've
provisionally made the text even more scary, as follows:

      Security Note: Some existing interactive user agents give advanced
      users the option of proceeding despite an identity mismatch.
      Although this behavior can be appropriate in certain specialized
      circumstances, in general it needs to be exposed only to advanced
      users and even then needs to be handled with extreme caution, for
      example by first encouraging even an advanced user to terminate
      the connection and, if the advanced user chooses to proceed
      anyway, by forcing the user to view the entire certification path
      and only then allowing the user to accept the certificate on a
      temporary basis (i.e., for this connection attempt and all
      subsequent connection attempts for the life of the application
      session, but not for connection attempts during future application
      sessions).

Jeff still needs to review that text before we finalize it.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 12:11:41 -0600

> except to make the general statement: Great work!

Thanks! Comments inline.

> there's no reason to spend further time on this here.

You're right, it's not good to baldly state this SHOULD NOT without
justification. We'll work to propose appropriate text.

> True; I'd missed that point, and I'm happy with the newer, scarier text.

In this context, scary is good. :)

> again, it's a very good piece of work.

Aha, thanks for the more detailed description of the scenario you had in
mind. I see your point. We certainly don't mean the recommendations in
this document to make life more difficult for your mother as she
interacts with her auto-configuring email client!

Off the top of my head I don't have a proposed solution, but I have
added this to the list of open issues that Jeff and I need to discuss,
and we'll be back with proposed text just as soon as we're able.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 12:18:53 -0600

On 9/22/10 12:14 PM, Jeffrey Hutzelman wrote:
> I think that's reasonable behavior _if_ the mail client knows that
> "gmail" is "mail.google.com".  What's _not_ reasonable is for it to
> arbitrarily transform "gmail" into a domain by adding ".com", then look
> up "gmail.com" and see that it is an alias for "mail.google.com" and not
> only follow the (insecure) alias to mail.google.com but also use it to
> decide that "mail.google.com" is an appropriate name to find in a
> certificate.
> 
> If your mother's mail client does that, then all I have to do to steal
> her password is convince said client that "gmail.com" is actually an
> alias for "stealgmailpassword.attacker.org".

In my experience, some user agents have interface elements such as a
drop-down box that lists popular service providers, and the account
configuration wizard behaves differently (e.g., asks for different
information) depending on which popular service provider the user chooses.

Peter

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

---

From: ArkanoiD <[email-masked]>
Date: Wed, 22 Sep 2010 22:31:43 +0400

BTW, slightly offtopic here: whenever i connect to gmail.com, i get certificate
for mail.google.com. But i've yet to see any web browser to complain! Where is the magic?

---

From: Marsh Ray <[email-masked]>
Date: Wed, 22 Sep 2010 14:37:55 -0500

Going to https://gmail.com/ I get some kind of redirection to 
https://www.google.com/accounts/ServiceLogin...

I can confirm the silent redirect behavior on FF, an associate reports 
it on IE9. I tried IE8 but get the expected "cert was issued for a 
different website's address" error.

Hopefully I'm overlooking something simple, but at first glance it would 
seem like either of these two conditions are true:

So what does gmail.com have in this situation that an attacker couldn't 
obtain for phonygmail.com?

- Marsh

;; QUESTION SECTION:
;gmail.com.			IN	ANY

;; ANSWER SECTION:
gmail.com.		86400	IN	SOA	ns1.google.com. dns-admin.google.com. 1427981 
21600 3600 1209600 300

;; ADDITIONAL SECTION:

;; Query time: 54 msec

marsh@lamb:/tmp$ openssl s_client -connect gmail.com:443
...
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=mail.google.com
issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
...
---
GET / HTTP/1.0

HTTP/1.0 200 OK
Date: Wed, 22 Sep 2010 19:31:43 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: 
PREF=ID=8614650b9dda6802:TM=1285183903:LM=1285183903:S=B88jR4IHVEMJ7oJ7; 
expires=Fri, 21-Sep-2012 19:31:43 GMT; path=/; domain=.google.com
Set-Cookie: 
NID=39=nR1SfxSCd9I9frwdHUXGHtOKWCI2yKMLaVWVnRZk50jDJv4InnuJPuhruGHy2j8hWeKdBfO18SCZzEm6N0qMW_flPF6tF6i-CvhRU1DrDDYvExygPnpew69GRLaWZeI0; 
expires=Thu, 24-Mar-2011 19:31:43 GMT; path=/; domain=.google.com; HttpOnly
Server: gws
X-XSS-Protection: 1; mode=block

<!doctype html><html><head><meta http-equiv="content-type" 
content="text/html; 
charset=ISO-8859-1"><title>Google</title><script>window.google={kEI:"n1maTNKCA5O8zAXDpJFW",kEXPI:"24956,26758",kCSI:{e:"24956,26758",ei:"n1maTNKCA5O8zAXDpJFW",expi:"24956,26758"},ml:function(){},kHL:"en",time:function(){return(new 
Date).getTime()},log:function(b,d,c){var a=new 
Image,e=google,g=e.lc,f=e.li;a.onerror=(a.onload=(a.onabort=function(){delete 
g[f]}));g[f]=a;c=c||"/gen_204?atyp=i&ct="+b+"&cad="+d+"&zx="+google.time();a.src=c;e.li=f+1},lc:[],li:0,Toolbelt:{}};
window.google.sn="webhp";window.google.timers={load:{t:{start:(new 
Date).getTime()}}};try{}catch(u){}window.google.jsrt_kill=1;
var _gjwl=location;function _gjuc(){var 
e=_gjwl.href.indexOf("#");if(e>=0){var 
a=_gjwl.href.substring(e);if(a.indexOf("&q=")>0||a.indexOf("#q=")>=0){a=a.substring(1);if(a.indexOf("#")==-1){for(var 
c=0;c<a.length;){var d=c;if(a.charAt(d)=="&")++d;var 
b=a.indexOf("&",d);if(b==-1)b=a.length;var 
f=a.substring(d,b);if(f.indexOf("fp=")==0){a=a.substring(0,c)+a.substring(b,a.length);b=c}else 
if(f=="cad=h")return 0;c=b}_gjwl.href="/search?"+a+"&cad=h";return 
1}}}return 0}function _gjp(){!(window._gjwl.hash&&
window._gjuc())&&setTimeout(_gjp,500)};
window._gjp && _gjp()</script><style 
id=gstyle>body{margin:0}#gog{padding:3px 8px 
0}td{line-height:.8em}.gac_m 
td{line-height:17px}form{margin-bottom:20px}body,td,a,p,.h{font-family:arial,sans-serif}.h{color:#36c;font-size:20px}.q{color:#00c}.ts 
td{padding:0}.ts{border-collapse:collapse}em{font-weight:bold;font-style:normal}.lst{width:496px}.tiah{width:458px}input{font-family:inherit}a.gb1,a.gb2,a.gb3,a.gb4{color:#11c 
!important}#gog{background:#fff}#gbar,#guser{font-size:13px;padding-top:1px 
!important}#gbar{float:left;height:22px}#guser{padding-bottom:7px 
!important;text-align:right}.gbh,.gbd{border-top:1px solid 
#c9d7f1;font-size:1px}.gbh{height:0;position:absolute;top:24px;width:100%}#gbs,.gbm{background:#fff;left:0;position:absolute;text-align:left;visibility:hidden;z-index:1000}.gbm{border:1px 
solid;border-color:#c9d7f1 #36c #36c 
#a2bae7;z-index:1001}.gb1{margin-right:.5em}.gb1,.gb3{zoom:1}.gb2{display:block;padding:.2em 
.5em}.gb2,.gb3{text-decoration:none;border-bottom:none}a.gb1,a.gb2,a.gb3,a.gb4{color:#00c 
!important}a.gb2:hover{background:#36c;color:#fff 
!important}#gbar{display: none}#gbe{display: 
none}body{background:#fff;color:black}input{-moz-box-sizing:content-box}a{color:#11c;text-decoration:none}a:hover,a:active{text-decoration:underline}.fl 
a{color:#4272db}a:visited{color:#551a8b}a.gb1,a.gb4{text-decoration:underline}a.gb3:hover{text-decoration:none}#ghead 
a.gb2:hover{color:#fff!important}.ds{display:-moz-inline-box}.ds{border-bottom:solid 
1px #e7e7e7;border-right:solid 1px 
#e7e7e7;display:inline-block;margin:3px 0 
4px;margin-left:4px}.sblc{padding-top:5px}.sblc 
a{display:block;margin:2px 
0;margin-left:13px;font-size:11px;}.lsbb{background:#eee;border:solid 
1px;border-color:#ccc #999 #999 
#ccc;height:30px;display:block}.lsb{background:url(/images/srpr/nav_logo14.png) 
bottom;font:15px 
arial,sans-serif;border:none;color:#000;cursor:pointer;height:30px;margin:0;outline:0;vertical-align:top}.lsb:active{background:#ccc}.lst:focus{outline:none}.ftl,#fll 
a{margin:0 12px}#addlang a{padding:0 3px}.gac_v div{display:none}.gac_v 
.gac_v2,.gac_bt{display:block!important}</style><script>google.y={};google.x=function(e,g){google.y[e.id]=[e,g];return 
false};window.gbar={qs:function(){},tg:function(e){var 
o={id:'gbar'};for(i in 
e)o[i]=e[i];google.x(o,function(){gbar.tg(o)})}};</script></head><body 
bgcolor=#ffffff text=#000000 link=#0000cc vlink=#551a8b alink=#ff0000 
onload="document.f.q.focus();if(document.images)new 
Image().src='/images/srpr/nav_logo14.png'" ><textarea id=csi 
style=display:none></textarea><iframe name=wgjf 
style=display:none></iframe><div id=ghead><div id=gog><div id=guser 
width=100%><nobr><span id=gbn class=gbi></span><span id=gbf 
class=gbf></span><span id=gbe><a 
href="/url?sa=p&pref=ig&pval=3&q=http://www.google.com/ig%3Fhl%3Den%26source%3Diglk&usg=AFQjCNFA18XPfgb7dKnXfKz7x7g1GDH1tg" 
class=gb4>iGoogle</a> | </span><a href="/preferences?hl=en" 
class=gb4>Search settings</a> | <a 
href="https://www.google.com/accounts/Login?hl=en&continue=https://www.google.com/" 
class=gb4>Sign in</a></nobr></div><div class=gbh style=left:0></div><div 
class=gbh style=right:0></div></div></div> <center><br clear=all 
id=lgpd><div id=lga><img src="images/logos/ssl_logo_lg.gif" width=276 
height=110 border=0><br></div><font size=-1>Go to <a 
href="http://www.google.com/">classic Google</a>.</font><form 
action="/search" name=f><table cell

---

From: Marsh Ray <[email-masked]>
Date: Wed, 22 Sep 2010 14:57:28 -0500

On 09/22/2010 01:31 PM, ArkanoiD wrote:
 > certificate for mail.google.com. But i've yet to see any web browser
 > to complain! Where is the magic?

> browsers with an entry for gmail.com.

This search
http://mxr.mozilla.org/mozilla1.9.2/search?string=[^%40]gmail.com&regexp=1&hitlimit=&tree=mozilla1.9.2

Doesn't return any hits. That search page is a little tricky though. It 
kept wanting to change my "^@" to "\0"! :-)

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Thu, 23 Sep 2010 13:33:54 -0500

On 09/23/2010 01:10 PM, Richard L. Barnes wrote:
>  Your browser is following two secure delegations before it lands at
>  www.google.com (gmail.com -> mail.google.com -> www.google.com).

I'd not even considered SNI.

> My guess based on the anecdotes in the thread is that IE8 doesn't
> support it.

Not IE8, but the pre-Vista Windows I was testing it on that doesn't do
extensions by default.

Which is why I'd not considered that gmail would depend on SNI for
its operation. I'd forgotten that this is Google we were talking about 
and not any other company in the world that would put support for MSIE 
on Windows XP ahead of protocol standards. :-)

>  MUST include a Host header field in all HTTP/1.1 request messages

Yep, that's why I requested HTTP/1.0.

- Marsh