Subject: [Acme] WGLC comments: draft-ietf-acme-tls-alpn-01 (Re: Confirming consensus)

From: Sean Turner <[email-masked]>
Date: Wed, 8 Aug 2018 22:31:54 -0400

Couple of comments:

0) s2: Use the update text:

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
 "MAY", and "OPTIONAL" in this document are to be interpreted as
 described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
 appear in all capitals, as shown here.

1) s3: For the base64URL safe text can you point to the base document; I think it’s s6.1?  

2) s3/s5.1: OID CLASH!  id-pe 30 is already assigned.  See:
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1

3) s4: Insert obligatory reference to RFC4086 (https://datatracker.ietf.org/doc/rfc4086/) for the randomness considerations of the token.  I’ll submit something against acme-acme so you may just be able to borrow that.

4) General: How are you addressing the algorithm agility concerns raised in BCP 201 (https://datatracker.ietf.org/doc/rfc7696/)?  Is it just going to be v2 if you need SHA-384?

5) General: Okay so I’m no cryptographer, but should the hash algorithm used in the challenge correspond to the hash algorithm used in the PRF/HKDF?  I mean if I’m going to use TLS 1.3 and TLS_AES_256_GCM_SHA384 should I really use SHA-256?

6) s5: I’d probably just add the following in s5.  I think everybody knows what’s going on, but it’s good to be specific:

[[RFC Editor: please replace XXXX below by the RFC number.]]

spt

> On Jul 18, 2018, at 15:56, Salz, Rich <rsalz=[email-masked]> wrote:
> 
> For completeness, these are 
>                 draft-ietf-acme-acme-13
>                 draft-ietf-acme-tls-alpn-01
>                 draft-ietf-acme-ip-02
>  
> From: Rich Salz <[email-masked]>
> Date: Wednesday, July 18, 2018 at 2:47 PM
> To: "[email-masked]" <[email-masked]>
> Subject: Confirming consensus
>  
> As discussed in a separate thread, we added mandatory-to-implement JSON signing crypto (TLS 1.3 signing algorithms); note that this does not affect the certificates themselves.
>  
> We decided to move draft-ietf-acme-tls-alpn and draft-ietf-acme-ip to working group last call.
>  
> If you disagree with either of these decisions, please speak up by Monday.  Note that the WGLC for the main document is being re-run in parallel with IESG and soon IETF review.
>  
>  
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Aug 2018 13:44:52 +1000

> 5) General: Okay so I’m no cryptographer, but should the hash algorithm used in the challenge correspond to the hash algorithm used in the PRF/HKDF?  I mean if I’m going to use TLS 1.3 and TLS_AES_…

The same input isn't fed into two different PRFs, so I believe that this is OK.

---

From: Roland Shoemaker <[email-masked]>
Date: Fri, 10 Aug 2018 11:15:03 -0700

Thanks for taking a look. I’ve opened https://github.com/rolandshoemaker/acme-tls-alpn/pull/6/files to address most of these comments.

For (4) the plan is to simply version it as suggested, that’s why we went with a two part OID with the base and then a versioned extension. If we need to rotate to a new algorithm we can simply increment that and define whatever new algorithm we want in another document.

For (5) I agree with Martin, the input isn’t being duplicated across two different PRFs so there shouldn’t really be a problem here.

Once these changes are merged I’ll send an email to Russ Housley to get the OID registered, I could swear I already did this but apparently not.

> On Aug 8, 2018, at 7:31 PM, Sean Turner <[email-masked]> wrote:
> 
> Couple of comments:
>