To: "Sriram, Kotikalapudi (Fed)" <kotikalapudi.sriram@nist.gov>,
 The IESG <iesg@ietf.org>
References: <148353798879.13011.5291414579598073386.idtracker@ietfa.amsl.com>
 <DM2PR09MB0446A3E1696278FBD040707F84600@DM2PR09MB0446.namprd09.prod.outlook.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <304ad58d-fa44-45e3-6fb1-4e7b189007cd@cs.tcd.ie>
Date: Thu, 5 Jan 2017 14:26:59 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <DM2PR09MB0446A3E1696278FBD040707F84600@DM2PR09MB0446.namprd09.prod.outlook.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
 micalg=sha-256; boundary="------------ms010702050903010705030903"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/tAYHVAVmk9hOzpOWZexpdPR8gsA>
Cc: "draft-ietf-sidr-bgpsec-protocol@ietf.org"
 <draft-ietf-sidr-bgpsec-protocol@ietf.org>,
 "sidr-chairs@ietf.org" <sidr-chairs@ietf.org>,
 "m.waehlisch@fu-berlin.de" <m.waehlisch@fu-berlin.de>,
 "sidr@ietf.org" <sidr@ietf.org>
Subject: Re: [sidr] Stephen Farrell's Discuss on
 draft-ietf-sidr-bgpsec-protocol-21: (with DISCUSS and COMMENT)
Precedence: list

This is a cryptographically signed message in MIME format.

--------------ms010702050903010705030903
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Hiya,

On 05/01/17 14:10, Sriram, Kotikalapudi (Fed) wrote:
> Stephen,
>=20
> Thank you for the detailed review and comments.
> Please see my responses marked with [Sriram] inline below.
>=20
> [Sriram] Your DISCUSS points (1) and (3) were already
> discussed /being discussed in separate threads.

Yep, thanks. I need to check back to see how close we are
to resolving those, but I had thought the ball wasn't in my
court at the moment:-) I'm sure we'll sort 'em soon though.

>=20
>> (2) Figure 8: It seems to me to be an error to omit the
> signer's ASN from the signed data and only have that
> included in the signer's certificate. Why is that intimate
> level of binding to the RPKI desirable? There may well be
> reasons but I'm not seeing 'em, and I am recalling that it
> took a chunk of effort to make CMS less dependent on
> X.509 for similar reasons (meaning identifying signers
> exclusively via cert issuer and serial in that case).  I
> would expect that there could be demand to have some level
> of independence between BGPsec and RPKI for at least
> internal uses such as those noted in the spec already.
>=20
> [Sriram] Signer's ASN is indeed included in the signed data.
> In Figure 8, "Secure_Path Segment : N" corresponds
> to the signing AS (current AS) and that is where the=20
> signer's ASN is included along with its pCount and Flags.

Hmm. That's the target ASN of the previous signer though.
I thought there were cases where they could differ? But
if not, then you probably need to state that as a rule
for checking signatures, is that there already? (Happy to
check later, but don't have time right now.)

One other thing below...

>=20
>> ----------------------------------------------------------------------=

>> COMMENT:
>> ----------------------------------------------------------------------=

>=20
>> - Figures 2 and 5 present the fields in different orders.
> That seems like a bad idea.
>=20
> [Sriram] Good catch. Already fixed in my editor copy of version-22.=20
>=20
>> - 3.2: The reference to the pki profile doc is not precise
> enough, the string "key identifier" does not occur in that
> draft - it's in RFC6487, 4.8.2.=20
>=20
> [Sriram] Again, a good catch. Already fixed in my editor copy of versio=
n-22. =20
>=20
>> - 4.1, last para: is the distinction between an "internal
> peer" and "iBGP peer" sufficiently clear to routing folk?
> For me they sound similar but I assume it's ok.
>=20
> [Sriram] I think it is well understood. But when I push version-22 out,=
=20
> I=E2=80=99ll consider if I should simply just use "iBGP peer" consisten=
tly=20
> and avoid using "internal peer".=20
>=20
>> - 5.2, I think you need to say something to the effect
> that every Secure_Path MUST have a signature with an
> algorithm that is supported. As I read the text, the
> algorithm as stated here could be read to not require
> that. E.g. the para before the bullets on p25 could be
> read to mean "drop all stuff involving unsupported algs
> and then continue to process the rest of the stuff."
>=20
> [Sriram] Seems like a bit of a pathological case.=20
> Could happen only if the sender behavior was incorrect.=20

Yes, but 5.2 is verifier behaviour and out not
assume a correct signer, so I do thing the alg
presented here needs to cover such things.

> Sender is not required to know which algorithms a peer supports=20
> but sender's expected behavior is this: MUST include a Signature_Block =

> for the "current" algorithm (which every BGPsec speaker=20
> MUST support through the transition period),=20

Where does it say that the current/next thing applies
to the entire world of BGPsec? I didn't read it that
way as it happens, but rather that the current/next
could involve different algorithms at different nodes
at the same time.

So e.g. I read it to be allowed that a migration from
rsa/sha256 then to ecdsa then to eddsa could occur
with some non-updated nodes still signing with rsa/sha256
whilst some shiny new nodes are doing ecdsa and eddsa and
others are in between.

I do agree that a global current/next pair of algs
is nicer, if that is what's wanted. But I don't recall
the text saying that. (Again happy to check later, but
no time right now;-)

Cheers,
S.


> and if the sender supports the "next" algorithm,=20
> then it MUST include a Signature_Block for the "next" algorithm also.
> So the peer BGPsec receiver (who MUST support=20
> at least the "current" algorithm) is not expected to be starved=20
> of a Signature_Block it can work with.  =20
>=20
>> - section 7: WRT non-deterministic signature algorithms, I
> think it'd be useful to note here that all such algorithms
> require good random number generation on the signer's
> system and that failing in that respect can expose the
> signer's private key.  IMO deterministic signature schemes
> are better for this reason but the need for a good RNG is
> I think a real operational issue worthy of note.
>=20
> [Sriram] I will include wording to cover this in Section 7 in version-2=
2.
>=20
> Sriram=20
>=20


--------------ms010702050903010705030903
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ
BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD
ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll
bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw
aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA
Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra
C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3
rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5
R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r
dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt
3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ
QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv
BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5
BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu
Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll
bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc
MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE
MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG
9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD
C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9
U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM
aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai
9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC
BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE
BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs
IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g
QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC
SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC
ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv
mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm
VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4
D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI
dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu
N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE
FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp
MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE
WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG
JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+
SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g
BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv
bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY
0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF
NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9
uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p
6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv
Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu
mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7
RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO
/ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN
JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM
MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG
A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0
Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA
oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDUx
NDI2NTlaMC8GCSqGSIb3DQEJBDEiBCAHjn57WMyRldaEwcP8gfzmam3rER8NrTwdCyF9w+ML
LjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0
Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw
IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB
nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD
VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq
hkiG9w0BAQEFAASCAQA+GifCgGcjRwlGht3SKDmq7dlaLDtlKmbqePcnBi4ieQFoYfhV9sdl
j9BUCOyssfR3HTrHJWMSIBaqBDUBCezkx1dYOFbi513koctmx1tPFNl97sNr7iD6SdM0RnAg
GJePA4nSyucwIdnM3lWkMktxLhqwvN7ST0XewpjiPDoFat0UlYmOCl3shLXK5pMgcjWsgngR
ryB0J4Q8OgRcwx7cW961qYTxTAXux9Qt5Gf8ktzskHzagItYIdolmAztwl7ToMdsRRPYFfq/
av0/wstIge9V/L5CI+9UCXNAhrxpfDT5R4TMILc0RrLz7X7XmQbswygn3IxkDqPp0zMvTvCL
AAAAAAAA
--------------ms010702050903010705030903--