{"action":"opened","issue":{"url":"https://api.github.com/repos/tlswg/tls13-spec/issues/1035","repository_url":"https://api.github.com/repos/tlswg/tls13-spec","labels_url":"https://api.github.com/repos/tlswg/tls13-spec/issues/1035/labels{/name}","comments_url":"https://api.github.com/repos/tlswg/tls13-spec/issues/1035/comments","events_url":"https://api.github.com/repos/tlswg/tls13-spec/issues/1035/events","html_url":"https://github.com/tlswg/tls13-spec/issues/1035","id":238736620,"number":1035,"title":"Overlap of signature algorithms with different semantics","user":{"login":"nmav","id":1745073,"avatar_url":"https://avatars1.githubusercontent.com/u/1745073?v=3","gravatar_id":"","url":"https://api.github.com/users/nmav","html_url":"https://github.com/nmav","followers_url":"https://api.github.com/users/nmav/followers","following_url":"https://api.github.com/users/nmav/following{/other_user}","gists_url":"https://api.github.com/users/nmav/gists{/gist_id}","starred_url":"https://api.github.com/users/nmav/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nmav/subscriptions","organizations_url":"https://api.github.com/users/nmav/orgs","repos_url":"https://api.github.com/users/nmav/repos","events_url":"https://api.github.com/users/nmav/events{/privacy}","received_events_url":"https://api.github.com/users/nmav/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-06-27T04:51:10Z","updated_at":"2017-06-27T04:51:10Z","closed_at":null,"body":"TLS 1.3 section 4.2.3.  Signature Algorithms contains:\r\n```\r\n          /* ECDSA algorithms */\r\n          ecdsa_secp256r1_sha256(0x0403),\r\n          ecdsa_secp384r1_sha384(0x0503),\r\n          ecdsa_secp521r1_sha512(0x0603),\r\n```\r\nThese overlap with sha256(4), sha384(5), sha512(6) with ecdsa(3) from RFC5246, though they have different semantics to the level they can be considered different algorithms.\r\n\r\nTo overcome that inconsistency TLS 1.3 includes that text:\r\n\r\n> If TLS 1.2 is negotiated, implementations MUST be prepared\r\n> to accept a signature that uses any curve that they advertised in\r\n> the \"supported_groups\" extension.\r\n\r\nSo the interpretation of this extension data can only happen after the TLS version is negotiated, because that's necessary to translate the code points to their actual meaning. Given that negotiation of TLS version is also done with an extension which can be present after the signature algorithms extension, that re-use feels like an unnecessary complication.\r\n\r\nIs there a particular advantage of re-using the code points for the the new signature algorithms in TLS 1.3? Wouldn't it make more sense to assign new code points to the new algorithms similarly to what it was done for RSA-PSS?\r\n"}}
{"actor":{"display_login":"nmav"}}