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

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

(Ben Campbell) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2017-02-01 for -12)
No email
send info
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.

(Spencer Dawkins) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2017-02-01 for -12)
No email
send info
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

(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

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

(Joel Jaeggli) No Objection

(Suresh Krishnan) No Objection

(Mirja K├╝hlewind) No Objection

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2017-02-01 for -12)
No email
send info
I agree with Stephen's comments.

Alvaro Retana No Objection

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