-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Thanks for the feedback! More inline ...
On 2/16/15 10:01 AM, Viktor Dukhovni wrote:
>
> [ Note, I've read only the changes from -08, not the whole
> document. ]
>
> Section 3.4 (Impact on TLA Usage) second bullet:
>
> Revert change from -08 to -09. The -08 language:
>
> If the TLSA response is "insecure", then the client SHALL proceed
> ...
>
> was correct, the -09 language opens the door to downgrade attacks:
>
> If the TLSA lookup fails, then the client SHALL proceed as if the
> ...
>
The original language did not account for the lack of records, but I
can see how this is too permissive. Perhaps the following is more
acceptable (replacing the last two bullets in dane-srv-09)?
o If the TLSA response is "bogus" or "indeterminate" (or the lookup
fails for reasons other than no records), then the client MUST
NOT connect to the target server (the client can still use other
SRV targets).
o If the TLSA response is "insecure" (or no TLSA records exist),
then the client SHALL proceed as if the target server had no TLSA
records. It MAY connect to the target server with or without
TLS, subject to the policies of the application protocol or
client implementation.
> Section 3.1 (Srv Query):
>
> Quote:
>
> If the lookup result is "insecure" (or no SRV records are located),
> this protocol does not apply and the client SHOULD fall back to its
> non-DNSSEC, non-DANE (and possibly non-SRV) behavior. If the SRV
> lookup fails because the RRset is "bogus", the client MUST abort
> its attempt to connect to the desired service.
>
> Note that *any* SRV lookup error, not just "bogus" needs to
> trigger connection failure. Timeout, SRVFAIL, ... all of these
> are potential downgrade attacks. Here, error is in the sense of
> section 2.1.1 of the SMTP draft (NXDOMAIN either "secure" or
> "insecure" is NOT an error).
>
> In light of that, the parenthetical comment "(or no SRV records
> are located)" should perhaps be made more precise.
>
> (or the lookup result is a denial of existence, whether "secure" or
> "insecure", but is not a lookup error)
The parenthetical is meant to account for the lack of SRV records, but
I can see how that might be too permissive. Is the following more
acceptable?
If the SRV lookup fails because the RRset is "bogus" (or the lookup
fails for reasons other than no records), the client MUST abort its
attempt to connect to the desired service. If the lookup result is
"insecure" (or no SRV records exist), this protocol does not apply
and the client SHOULD fall back to its non-DNSSEC, non-DANE (and
possibly non-SRV) behavior.
>
> Also please update your xml2rfc reference cache, the SMTP draft
> reference should be to version 13.
>
Thanks for the catch. I'll force a cache refresh.
- --
- - m&m
Matt Miller < [email protected] >
Cisco Systems, Inc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJU4ipwAAoJEDWi+S0W7cO1IAwH/jm69XKWbgc+r1Wxrayrt6cG
Tb05iVU3JNUZlEn1ATw6J0HCasaY/9AKqOUQTOl6kU56aWOUvZV2lVB62+h1mcI6
sqTOillrK7bvAoWLJRzCoFchsVZqmaCv0ZkimMwnDj36/lJC07BZxsvRWTknKOCK
8JtdCm6JbkxadO5trkNoL2y5u9Ca5LBCBbNNAsA5AdlVzAlQDwFJDNMF1gP0Tfpw
rx3jADKoojWnSfNu0QFh2biiefjW1IEWnGqXxCqZCsguVcAjKYqCQWkKlN4tI7Ok
V5ryDFX512UwKTluBf+lti/xFr9NrEeeUzyfwEXZ21bf1Zx8WqW1u5RI1BlLt3g=
=hnNh
-----END PGP SIGNATURE-----
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
