Skip to main content

Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)
RFC 8122

Yes

(Ben Campbell)

No Objection

(Alia Atlas)
(Deborah Brungard)
(Jari Arkko)
(Joel Jaeggli)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 12 and is now closed.

Alvaro Retana No Objection

Comment (2017-01-31 for -12)
RFC4572, which this document obsoletes, Updates RFC4145.  I'm wondering why this document doesn't Update RFC4145 too?

(Ben Campbell; former steering group member) Yes

Yes (for -12)

                            

(Alia Atlas; former steering group member) No Objection

No Objection (for -12)

                            

(Alissa Cooper; former steering group member) No Objection

No Objection (2017-02-01 for -12)
Section 5.1 says:

"An endpoint MAY, in addition to its more preferred hash function,
   also verify that each certificate used matches fingerprints
   calculated using other hash functions.  Unless there is a matching
   fingerprint for each tested hash function, the endpoint MUST NOT
   establish the TLS connection."

This seems a little weird to me. It's up to the endpoint to decide whether to check for errors, and then if it does find an error it can't setup the connection, whereas if it just hadn't checked it would be able to setup the connection. I think it would help to explain why an endpoint would be motivated to check multiple fingerprints.

(Deborah Brungard; former steering group member) No Objection

No Objection (for -12)

                            

(Jari Arkko; former steering group member) No Objection

No Objection (for -12)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -12)

                            

(Kathleen Moriarty; former steering group member) No Objection

No Objection (2017-02-01 for -12)
I agree with Stephen's comments.

(Mirja Kühlewind; former steering group member) No Objection

No Objection (for -12)

                            

(Spencer Dawkins; former steering group member) No Objection

No Objection (for -12)

                            

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2017-02-01 for -12)
I had two (or 4 depending how you count:-) things
I'd like to check here. They were pretty easy to
handle. (We more or less resolved this by mail.)

(1) section 5: I'm wondering if we have the right
set of hash functions here. Deprecating md2 and md5
is great, but I have a bunch of questions about the
others:

(1.1) why not also say that sha-1 MUST NOT be used
for new things (or similar)?

(1.2) do you really need sha-224 and 384? I think
nobody uses those at all.

(1.3) I'm a bit surprised you didn't add sha3 (and
maybe remove sha-512 if that's not needed) Even if
you don't encourage use of sha3, it might be good
to include it in the abnf now in case it gets
popular.

(2) Wouldn't it be a good plan to say that TLS
as-used MUST conform to BCP195? If not, why not?

(Suresh Krishnan; former steering group member) No Objection

No Objection (for -12)

                            

(Terry Manderson; former steering group member) No Objection

No Objection (for -12)