Subject: [Uta] (extra) WGLC for draft-ietf-uta-tls-bcp-07.txt

From: Leif Johansson <[email-masked]>
Date: Wed, 12 Nov 2014 01:52:30 +0100

Since there were so many LC on draft-ietf-uta-tls-bcp-06.txt the chairs
have decided to run an additional short WGLC on
draft-ietf-uta-tls-bcp-07.txt

Please make sure your comments have been addressed by reviewing the
document. We will be looking for a few explicit "+1" on the list to
indicate that review has been done.

To provide a little bit of time for post-IETF travel, this WGLC will
expire on 21/11

	Cheers Orit & Leif

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Nov 2014 11:04:59 +0000

This is good enough.

comments..

1) a nit in 4.3:

OLD:

   Servers SHOULD authenticate using at least 2048-bit certificates.

NEW:

   When using RSA servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.

I didn't spot the same thing elsewhere but it could be there.

2) 5.2 title and elsewhere - use "Opportunistic Security" and not
"Opportunistic Encryption" we had that (boring;-) debate so we may
as well stick to the outcome

3) Wrt Brian's point about DHE 1024, I think that was already discussed
on the list earlier and while the mozilla figures are interesting they
don't change my mind - I think the benefit of PFS and the fact that
s/w updates can fix this silently after one has configured the DHE
cipherstuite and that the draft already says you should use 2048 all
add to to where the draft is ok as-is.

Cheers,
S.

On 12/11/14 00:52, Leif Johansson wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 12 Nov 2014 08:47:38 -1000

> On 11 Nov 2014, at 14:52, Leif Johansson <[email-masked]> wrote:
> 

Looks good to me (other than the issues already reported by Stephen).

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 12 Nov 2014 18:17:20 -0700

>     at least a 2048-bit modulus for the public key.

Ack.

> I didn't spot the same thing elsewhere but it could be there.

I didn't see any other instances.

> as well stick to the outcome

Will fix in the title and in the running text.

> add to to where the draft is ok as-is.

That seems sensible to me.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Brian Smith <[email-masked]>
Date: Wed, 12 Nov 2014 18:48:16 -0800

> add to to where the draft is ok as-is.

Firstly, I am also a very big advocate for PFS. More than arguing
against the DHE variants of the cipher suites, I'm arguing for the
ECDHE variants.

I understand that this document is near the end of the road and that
changes should be minimized if possible. Also, re-reading the draft, I
think most of my concern is already addressed well enough in section
4.4. I'd like to propose one small additional bullet point to the list
of bullets in section 4.4:

+    o  Many server choose DH parameters of 1024 bits or fewer.
+
    o  There are widely deployed client implementations that reject
        received DH parameters if they are longer than 1024 bits.

CURRENT TEXT: "With regard to PKIX certificates, servers SHOULD
support OCSP and OCSP stapling, including the OCSP stapling extension
defined in [RFC6961], as a best practice given the current state of
the art and as a foundation for a possible future solution."

SUGGESTED NEW TEXT: "With regard to PKIX certificates, servers SHOULD
support OCSP and OCSP stapling, including both the status_request_v2
extension defined in [RFC6961] and the status_request extension
defined in Section 8 of [RFC6066], as a best practice given the
current state of the art and as a foundation for a possible future
solution."

In particular, I believe that the current text is intending to mean
the same thing as the suggested new text, but it is easy to
misunderstand it to be recommending only the status_request_v2
extension, and not also recommending the status_request extension.
(Indeed, this is how I read it last night, which is why I expressed
concern about it.)

What do you think?

I am content with all my other feedback being ignored, as it is less important.

Cheers,
Brian

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 12 Nov 2014 20:13:13 -0700

> (Indeed, this is how I read it last night, which is why I expressed

Your clarifications seem helpful to me, thanks!

> I am content with all my other feedback being ignored, as it is less important.

OK. But I for one will look at it more closely soon.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Leif Johansson <[email-masked]>
Date: Thu, 13 Nov 2014 05:30:10 +0100

> OK. But I for one will look at it more closely soon.

Since we are out of WGLC I would like to see at least some +1's from the
WG to make sure we're actually reflecting WG consensus here.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 13 Nov 2014 06:00:54 +0100

> WG to make sure we're actually reflecting WG consensus here.

Ok I realize that needs clarification.

What I meant to say was this: give that we are doing a second WGLC it is
really important that we are doing edits that reflect WG consensus.

Clearly some edits are of an editorial nature and I believe we can trust
the editors to handle those.

	Cheers Leif

---

From: Chris Newman <[email-masked]>
Date: Wed, 12 Nov 2014 21:43:58 -1000

> WG to make sure we're actually reflecting WG consensus here.

I have read version -07, and as with my review of version -01 I support
publication of this document or a similar document. If anything, more time has
been spent improving this document than was necessary; it is now unusually high
quality for an RFC.

		- Chris

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 13 Nov 2014 11:28:33 +0000

> WG to make sure we're actually reflecting WG consensus here.

I'm fine with the changes suggested in Brian's last mail.

That said, I'm not confident I know the impact of the change
to 7.5 (the OCSP stuff) as I've not gone looking at code nor
thought about any ops issues that could arise, but it looks
reasonable for sure, so is probably ok unless someone yells.

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 13 Nov 2014 10:47:32 -0500

> That said, I'm not confident I know the impact of the change to 7.5 (the OCSP
> stuff) as I've not gone looking at code nor thought about any ops issues that
> could arise, but it looks reasonable for sure, so is probably ok unless
> someone yells.

I just re-read the document, particularly 7.5.  I'd move the two CRL bullets together (i.e., "and the last shall be second" as it were).  And in the second (to become third) bullet, I think the privacy issues are particularly important for non-heavy-traffic web servers, so I'd remove that whole when close at the end of the first sentence.

But other than those two minor quibbles, it looks very good.  +1 ( I was pleasantly surprised to see my name in sec 8 :)

--  
Principal Security Engineer, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 13 Nov 2014 19:15:49 -0700

> Your clarifications seem helpful to me, thanks!

The authors have given this further consideration and we have a 
question: in practice will it be OK to send *both* status_request and 
status_request_v2 in the same handshake?

Peter

--
Peter Saint-Andre
https://andyet.com/

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Dr. Massimiliano Pala" <[email-masked]>
Date: Thu, 13 Nov 2014 16:59:12 -1000

Hi all,

If it is not too late... regarding Session 7.5 - first bullet point: the 
text seems a bit too restrictive. Probably in the context of current Web 
Browser CRLs are not used today, but other environments still make a 
wide use of CRLs. I also would like to add a privacy consideration about 
the use of CRLs vs. other mechanisms.

For this I would the text from:

    Certificate Revocation Lists (CRLs) are not scalable and therefore
    rarely used.

to something like the following:

    Certificate Revocation Lists (CRLs) provide the most supported
    revocationinformation distribution mechanism. Although updates to
    the CRLformat (e.g., partitioned CRLs, delta CRLs) have been defined
    toaddress scalability issues, they are rarely used in favor of more
    compact formats. However, it is important to notice that the use of
    CRLs might provide better privacy-preserving properties than other
    protocols (e.g., OCSP), especially when considering the validation of
    client-side certificate.

The last consideration stems from the fact that by using CRLs, a service 
does not need to communicate to the certificate issuing authority (e.g., 
the CA or the entity running an OCSP server) and disclose the 
certificate for which the revocation status is requested.

Cheers,
Max

---

From: Brian Smith <[email-masked]>
Date: Thu, 13 Nov 2014 23:04:32 -0800

On Thu, Nov 13, 2014 at 6:15 PM, Peter Saint-Andre - &yet
<[email-masked]> wrote:
> The authors have given this further consideration and we have a question: in
> practice will it be OK to send *both* status_request and status_request_v2
> in the same handshake?

If the client supports both, then it will include both in its ClientHello.

If the server supports both, and and the ClientHello only contains
status_request or status_request_v2 but not both, then obviously it
will just choose whichever one the client supported.

If the server supports both, and the ClientHello includes both, then
the server is free to choose status_request or status_request_v2 or
both. I think the intent of RFC 6961 is that only status_request_v2
would be sent in that case, but this isn't explicitly stated anywhere,
AFAICT. I wouldn't be surprised to find that a server that attempts to
implement RFC 6961 may have to include BOTH status_request and
status_request_v2, because I bet some middleboxes won't expect the
CertificateStatus handshake message unless the original status_request
extension is present. BUT, also, I wouldn't be surprised if some
clients refuse to accept a ServerHello with both status_request and
status_request_v2.

So, I guess now I'm unsure whether RFC 6961 (status_request_v2) is
even deployable. But, I know for a fact that the original RFC 6066
status_request mechanism is deployable, because many implementations
have deployed it. (It usually works without creating problems.
Sometimes it creates problems, but I think the problems are caused
primarily by bugs in servers that would also affect
status_request_v2.)

Note that I wouldn't mind if you removed the suggestion to implement
status_request_v2, given that we don't know much about it. I think
that would be prudent, though I don't care strongly about it. But, it
is really important to recommend the original RFC 6066 status_request
extension.

Cheers,
Brian